September 7th, 2017
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
Still caught by the nostalgia I mentioned in the 2nd previous post, I re-read Peter Williams post, linked via the same debate. I recall reading this in 2005.
Martin Fowler has posted a nice article on humane interface design (as opposed to minimal interface design). I am definitely on the side of right and good (read: humane interfaces) in this debate. Nothing takes the fun out of programming faster than having to write a bit of code that you know has already been written a bazillion times.Even if it is only a few lines code. When I program in Java, which exemplifies the minimal interface approach, I feel like this most of the time. I almost never feel that way in Ruby because humane interfaces are deeply ingrained in the community.
Minimal interfaces shift the maintenance burden to the clients. This is great for the library writer because they have less to maintain, but it is devastating for the community. Humane interfaces have the extra behavior because clients need them.It is rarely, if ever, appropriate to provide behavior that no one needs, regardless of the interface style style. The fact that a minimal interface does not provide an particular bit of behavior does not change the fact that clients need that behavior, it just means that that bit of behavior will be implemented independently in a significant subset of clients. This duplication of common but non-standard behaviors will, over time, significantly increase the total amount of code that a community has to maintain.
In the comments:
Replacabilty sets off my “you’re NOT gonna need it!” alarm. When is the last time you swapped implementations of an interface? I am not sure I have ever done it, at least not late enough in a project for it to matter.
But you do make a point that Java interfaces make this problem a lot more complicated than it needs to be. In my experience the vast majority of behaviors on a humane interface are mostly just mixing a series other, more primitive, behaviors together. If Java interfaces were more like abstract classes you could define a couple of abstract primitive methods and provide default implementations of the other 70 or so useful behaviors in terms of those few primitive behaviors. This gets you the best of both worlds.
I especially relate to the aversion to arguments based on replacing something. I’ve often heard this regarding using ORMs to mask databases. The suggestion is often something like “What if your company was using Oracle but now it wants to use Microsoft SQL Server?” But I’ve been programming for 18 years now and I’ve never seen this happen. I doubt I will ever see it. I have seen some companies change databases, but in every case the move was part of a greenfield project, and someone wrote an import script to pull the data from the old database, to the new database. It’s easy to write an import script, whereas ORMs are a permanent hit to productivity and performance.Source