Humane Interface Debate

I've been following the humane interface debate on James Robertson's blog. I can see both points of view. One side wants the minimal interface because it's easier to maintain the class implementing it. The other side wants a richer interface because it's easier to maintain the class using it. Notice both sides are interested in making it easier to maintain and both have valid points. Is there a compromise to be had?

I like having a minimal set of methods to implement because I make sure duplication and cognitive friction is reduced. But, the users of the class wind up with terse code that's harder to read than with a richer interface. It seems both sides of the argument will always be at odds. This is where I think concepts of object composition from prototype languages can help. "Organizing Programs Without Classes" is worth a study for it shows the way that we can have our cake and eat it too. We have all of the tools at our disposal right now in Ruby's mix-ins, Traits in VW and Squeak, and even in Java with some creative use of proxies and interfaces (yes, it might be slow, but premature opimization is evil right?).

Ruby's Enumerable mix-in is a perfect example of having our humane interface and minimal interface too. All we have to do is implement the minimal methods "each" and "<=>" on a new collection class. It keeps the cognitive friction to a minimum of what the class does and then, we simply mix-in Enumerable and we get "select", "detect", "collect", and just a whole slew of convience methods that makes our client code easier to read.

Traits implements a similiar idea for Smalltalk complete with browser support and it's a joy to use. It's available for both Squeak and VisualWorks. If you're a Smalltalker, you have no excuse not to look at it. I can't say enough good things about it.

I'm still thinking at what a Java option would look like. I'm thinking creative use of aspect-oriented programming or byte code manipulation should make the same thing possible. A poor man's solution could use interfaces, proxies, and the delegation pattern right off the bat.

Java is the real challenge in making code that reads well. In Smalltalk, it's easy because of the message syntax. It's not impossible, but it might be why Smalltalkers favor code that reads like a book rather than minimal interfaces. Anyway, I'm getting off-topic, but I believe there is a compromise in this debate that can satisfy both sides and I think that the resulting code is better for both the implementers and users of the class. We just needed to dig a little into our past of our prototype brothers and adapting some of their concepts for our class-based elders.

And if you haven't tried out mix-ins in Ruby or Traits in Smalltalk, do it now! You'll start thinking of your objects as compromised of behaviors and it allows you to break up your code into more manageable chunks. It also increases the reuse and readability. How much better could it be? Of course, you could play with Self or Io to see what class-less programming looks like. Who couldn't use a new tool or trick in their bag?