In one of the comments to Alan's Naming Classes Without a ‘Manager’ article, Darren Greaves suggests that Util could be another contender in the list of class names to avoid.
I disagree.
One of the tricky aspects of API design, especially when designing the base APIs for a programming language, is deciding what goes in, and what stays out. Think of a string. There are an enormous number of things you can do with strings, but to put all of those operations on the String class would just be impractical and bloated. So as the designer, you take those operations that you feel would be most generally beneficial, such as finding the length, searching for and extracting substrings, and so on, and leave out the rest.
Some languages, such as Smalltalk, Objective-C, Ruby, Python, Perl, CLOS... Okay, a great many languages allow you to add behaviour to existing classes. So, for example, if your application really needs a method that reverses a string in-place and the language designer has decided that's not necessary for the supplied String class, you can add your method directly to the String class and be done with it.
Some languages, and this is where Java sits, don't let you do this. If you want to extend a class, you have to subclass it. And then you're stuck with whatever the superclass has made visible. And you can't do it with String anyway, because String is final. This is why most projects I work on end up having a StringUtil class, and every project ends up with a DateUtil. There are things we want to do to strings and dates all the time, but there's no way to put those things where they really belong, on the String and Date classes. Which is why having a Util class isn't a code-smell per se, it's a smell in the underlying language.
Thus, ‘Util’ is shorthand for “stuff that belongs somewhere else, but I'm not allowed to put it there, damnit.”.
Of course, Alan also tells me that being able to dynamically add methods to classes is frequently abused, and usually a Bad Thing when writing large systems, but having used both approaches on a small scale, and vastly preferring the more dynamic approach, it's one of those things I'd like to be able to find out for myself, you know?
Update: In a comment, Chris Winters says:
Whenever I get the urge to put something in a 'Util' class, I first look at what the various Jakarta Commons groups have done.
This is incredibly good advice, and worth shouting louder. There's a lot of really useful stuff out there. That said, I recently found myself rather cynically reimplementing something I'd seen in jakarta-commons, because I didn't want to fight any battles over adding another dependent library to the project.
I've never written or used a StringUtil or a DateUtil class nor can I imagine what you would possibly want to put it one. I've had the unfortunate experience of working in systems where everything was wrappered by a util class "for portability". But, the idea was that the provided class was more of a mirror of the original and not intended to provide new functionality. That, of course, smells pretty bad to me...
Util doesn't smell bad for me, if I don't have multiple inheritance available.
I even wrote some Util classes for my own interfaces. Sometimes I was not able or not allowed to inherit from an abstract class containing common code. So, the next best thing was to have an Util class for it.
In most cases I called the public static methods inside Util in my Abstract class in order to avoid code duplication. Code duplication smells worse ;-)
Just my 0.02 €
Whenever I get the urge to put something in a 'Util' class, I first look at what the various Jakarta Commons groups have done. More than half the time what I was looking for has already been implemented, reviewed by multiple people and tested. Nice!
Hi, wanted to expand upon my brief two-line rant against utils.
I was more thinking of classes that are called *just* Util or Utils.
Specifically where they consist of groups of *unrelated* methods.
Related methods in a sensibly named class like StringUtil is fine.
I realise now that my comments were misleading given the context of the post I was responding to.
Oh, utils packages with a bunch of unrelated classes are pure evil though. :-)
nnnnUtil: bad. nnnnDecorator or nnnnWrapper: better.
Re: Objective-C categories. They don't simply allow you to extend a class per se by adding new behaviour but they also allow you to completely override or replace existing behaviour. This can sometimes be a problem and other times be boon. I work at a site where by we dynamically load in categories at runtime. Primarily because they don't want to rebuild the binaries and there's a strict patching via Categories approach in place. It actually speeds up development a lot because this is in the days of static link times and they are dreadful with anything of a non trivial size. I'm constantly spending my time patching patches to existing code. ie. writing categories that override other peoples categories etc. This is load/link time dependent. It just ends up being a new method in in the method list of a class that gets found first when the runtime does it's lookup. So technically speaking there are ways to still get to the IMP of the class being overridden by the cateogry.