jvdb.org Blog

Minimalist or Humane interfaces? Both ofcourse

on Saturday 10 December 2005 @ 23:51 in Software Construction

For some reason everybody has way more time on their hands to read blogs than I do, because whenever I feel like responding to a post from someone it turns out that it was written at least half a week ago and already has dozens of responses. Again here, concerning a recent post by Martin Fowler discussing humane interfaces. There are lots of responses, most of them listed at the bottom of his original posting. Trying to read through them I noticed that what I would consider the most important argument in the discussion is somehow present but not really discussed, so I decided to bring it up myself.

This whole discussion centers on whether an object should expose only the bare minimum functionality (called the minimalist approach) or additional functionality that may or may not be difficult to implement, but is typically required by programmers and can therefor be a great help by being included (called the humane approach). The example is Ruby’s Array class which has 78 methods defined, including methods such as first and flatten that can reasonably quickly be implemented by the client code, but can still be useful to have anyway.

A major argument for the humane approach is that if a class only defines the absolute basic operations, that users will end up duplicating a lot of code for common tasks. The major argument for the minimalist approach is that classes that define more than they have to will require more maintenance than they should.

Personally, I like it when objects can help me out with more than just returning a handle that I can use to query someone else for the next handle, all part of over ten different steps in order to complete a single functional step (anyone remember setting up something in DirectX? Is it still that bad?) That doesn’t mean maintenance is not an issue. I don’t think it’s reasonable to require that implementing an optimized version of a class means you have to rewrite 78 methods.

Instead I think it’s good to seperate the two: always create a class that exposes a minimalist API and then encapsulate it to add the humane interface on top of that. This way you can easily seperate the derived (humane) behaviour from the implementation-specific (minimalist) behaviour. Implementing a new minimalist version of a class will give all clients access to the humane interface with the new back-end. Is this really such a fundamental issue? I feel like everybody’s always been doing it like that.

Leave a Reply