Java is minimal only in the apidocs, not in our minds

The battle of Ruby vs. Java is breaking loose big time. You haven’t heard? Seriously? Well, I’m not going to add yet another blog entry with a summary of the whole discussion started by Martin Fowler; you’ll find an excellent summary on The Farm (but don’t stop there; you don’t want to miss, for example, Elliotte Rusty Harold discovering the versatility of Ruby’s Array class). My local Ruby guru advised me earlier on against comparing Ruby with Java, and I agree: you should use each language where it’s best suited.

But I would like to ask the ‘minimalists’ (pro-minimal interface, vs. humanists: pro-humane interface) this. In the last three years of Java coding, I haven’t been on a project where at least commons-lang, commons-collections and commons-beanutils weren’t included, from the start, and used throughout the code.[1] My point is, our (= coders) virtual interface to List/String/Class/etcetera does already contain all those extra, some say superfluous, methods. If I want to do a select(predicate) on a collection, I know I can — it’s just a matter of remembering which to use: Collection, Collections or CollectionUtils. But virtually, it’s just an operation on the Collection interface to me. However minimal the Collection interface is in the apidocs, in my mind there’s a lot more I can have a collection do. So if we’re generally aiming at keeping things simple, why aren’t these operations on the Collection interface itself? So what if it takes 78 methods, or 780 for all I care — if that’s where they belong, we should put them there instead of spreading them out artificially over utility classes.[2]

————

1. And even that wasn’t enough sometimes for fairly basic tricks, like the one I wanted to do just recently: convert a collection of objects to a map with key/value pairs coming from the objects’ properties. It’s not in commons-collections (let alone java.util.Collections). Yet another utility method added to the project, and not even trivial to code. While in Ruby, it’s nothing more than a fresh breeze of code…

map = {}
objects.collect {|obj| map[obj.key_property] = obj.value_property}

2. Why do people get nervous over big numbers so often? Isn’t that what we have computers for? And where should we place the limit? Obviously, 22 methods is ‘officially approved’, 78 is not; so is 23 okay? 24? Why should we have an arbitrary limit? Personally, I think it would be better to just consider the behaviour we want a class to have, no matter how many methods it takes.

2005-12-10. 2 responses.

Comments

  1. “Why do people get nervous over big numbers so often?”

    Have you ever tried to use a class that itself has a hundred methods and inherits hundreds more from other classes? The following isn’t quite that bad, but I think it makes Elliotte’s point very well: http://protege-owl.sourceforge.net/javadoc/edu/stanford/smi/protegex/owl/model/impl/DefaultOWLIndividual.html

    If you really think that more is better, why don’t you also add Graph and Tree operations to that Array too? That would be even more convenient.

  2. “The following isn’t quite that bad … ”

    Well quite contrary. Its a bad example because DefaultOWLIndividual class is definitely used by as many ppl as the java.util.* classes!

    Context is important. If I am writing a one time/one customer banking application and I decide to write a CreditAccount class, its upto me and my team to keep a minimal or hamane interface (or even Fluent for that matter, read the latest entry by Martin Fowler).

    But if I were writing a graphics or math library, the forces will be stronger in my mind to keep things humane (the ruby humane, not the Java humane!). For comparision’s sake, look at what has happened with the java.util.Date. Think JodaTime !!