“While it’s really nice to have a good api, an interface is supposed to be a set of operations that make it easy to code something that replacably works with other implementers of that interface. If you have a giant interface (say 78 methods for a list/array instead of 23) you make is substantially less likely that people are going to bother to use that interface when coding a new class because it’s 3 or 4 times the code to implement the much larger interface.”

I think you’re confusing an INTERFACE (capitals = abstract concept) with an interface (lowercase = Java keyword). Martin Fowler and Peter are referring to the former. The INTERFACE of the class MyArray is the set of methods that are exposed to the User. The NiftyArray interface is the collection of method signatures that the class MyArray must provide in order to “implement” NiftyArray. They are related: the INTERFACE of MyArray must necessarily be a superset of the NiftyArray interface. But they are not the same.

Now, let’s take interfaces out of the equation all together (Ruby doesn’t have them, nor does it need them). Left only with INTERFACEs we have only the methods provided. Fowler’s article get’s at the point that this set of methods shouldn’t necessarily be minimal. Providing that extra method which encapsulates a common 3 line use of the other functions within the INTERFACE — that’s GOOD, because now that’s 3 lines of code maintained in one place, rather than three lines repeated throughout many projects.

If you’re defining an interface that is expected to have several implementations, you probably do want it to be minimal while still being convenient. However, if you’re writing a definitive class, such as a class in a core library, splurge. Expand that INTERFACE and make life easier on your users.

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.

An extended “humane” interface would the feasible but I think that it suffers from all the issues you see with humane interfaces in general. Personally, I find that using a language that does not penalize providing humane interfaces quite so much a better choice. :)