Humane Interfaces: Fowler vs. Harold

Today I noticed an interesting exchange between two of my regular reads: Martin Fowler's blog and Elliotte Rusty Harold's Cafe au Lait web site. I respect both of the authors for their interesting view points which spark many an interesting thought, but on this occassion Elliotte has disappointed me.

Martin was discussing the value of what he terms 'Humaine Interfaces' - software interfaces which are designed to provide the methods you need with names that are easy to remember and type. Apologies for my explanation which is probably an oversimplification.

Elliotte comes in with an unsubstantiated expression of disapproval and claims that simplicity is key, and that too many methods is a bad thing.

Well in short, I disagree.

Do more methods automatically mean more complexity? No, they allow the methods to provide a better reflection of the underlying intention. Martin gives an example of the Ruby code:

anArray.last

compared with the Java:

aList.get(aList.size - 1)

Martin comments that the former is simpler to use, whilst Elliotte says that it presents a larger and therefore more complex API to use.

My view is that there is nothing to be lost by providing alternative and more specific methods within a class to deal with specific cases that users may require. The user of a class doesn't have to understand or memorise every method in order to use it. Scanning through method names isn't a chore as long as they are presented alphabetically. There are no significant processor cycles wasted by only using 2 out of 78 methods of a class.

Getting into the detail you start to see some real valuable reasons for using a more specific method rather than applying a more minimal set of methods to a task. In some implementations of a list, getting the size of a list, or getting the last element by it's index number might be very expensive, whilst a dedicated method for getting the last item may be able to be optimised in some useful way because it represents a special case.

It also avoids some of the silly mistakes that you get from forgetting whether to use:

aList.get(aList.size) or aList.get(aList.size - 1)

Of course there are no perfect answers. Being required to provide 78 methods to conform to some interface standard could be extremely frustrating, so I wouldn't advocate it for abstract methods / interfaces. Similarly, there's no value in having a rag-bag mix of every method name the author thought of over the last 3 years of development - the methods should be there for a good reason, well named and suitably documented.

Finally, if I'm going to agree with Elliotte at all, I guess I should express doubt in the value of method aliases. One of the values of Java over C is that it provides fewer ways of expressing the same thing. I can't see any great value in having two methods with different names that do exactly the same thing. In a collaborative project it would inevitably lead to situations where code confusing uses of both method names for no apparent reason. On the other hand, aliases in the method documentation would be good, e.g. you look for a method length() and it says "see method size()".