Software will save us

« The DRM Experience | Main | Instant autocomplete in Eclipse »

April 21, 2005

The almighty Util class

You are in need of a new method. Various rules of thumb (like the GRASP Patterns) strongly suggest that method belongs to Klass, but the source of Klass is not under your control. What do you do?

Some languages allow you to mess with existing namespaces:

• In Ruby you could simply reopen Klass and glue on method.

• In Perl it is possible to revisit packages but (unlike in Ruby) not everything is an object and modules from the CPAN feature varying degrees of OOPfulness.

• Javascript lets you extend classes in a way that makes it completely useless in practice. You see, Javascript's class tree is majorly fucked up and consistently inconsistent in all major browsers. If you retrieve a DOM node, there's no cross-browser way to tell which class it will have. document.getElementsByTagName returns some sort of collection, but it's not an Array. Hell, not even all objects descend from Object.

When you cannot extend classes like in Java or C#, chances are you will end up creating over-generic Util classes as StringUtil or JspUtil. The honorable Charles Miller blames this practice on the language:

Thus, 'Util' is shorthand for "stuff that belongs somewhere else, but I'm not allowed to put it there, damnit.".

Thoughtworker Darren Hobbs prefers to supply utility methods through concrete objects. For most purposes I agree. It is much nicer to have multiple, highly cohesive utility classes that each do one thing well instead of one bulky class of loosely related procedures.

Take Java's URLEncoder. URLEncoder does one thing which is, well, encode URLs. I will happily reuse a lightweight URLEncoder in my code. I'd be less enthusiastic about a gigantic NetworkUtil library, especially if we weren't talking about a built-in framework class.

I wonder if there will ever be a language which truly embraces Dependency Injection down to the level of its core classes. Even if all a method does is to create and return a String, my application should be able to control which kind of String is produced. I'm aware that this stretches the notion of Dependency Injection and might potentially break a million other things but hell would I love to read about more ideas along these lines!

Comments

Posted by Aristotle Pagaltzis (#)

Posted by Henning (#)

Post a comment