Wednesday, June 16, 2010

How to avoid Design – The ‘*.common.util’ package

I’ve seen a lot of code that makes use of a ‘util’ package; in a limited domain, I guess I don’t really have an issue with this.  A utility package would likely contain some static classes that do things like parsing strings, formatting, sorting, certain calculations…the list is endless.  There are just some things that need to be static and available and rather than think about design, we pop it into a class called ‘StringFormatUtils’ and pop it into the util package so that we can remember to look for it in six month’s time.

The fatal flaw here is that looking for some obscure little function that worked once among a sea of formatters and parsers is just not going to happen.  Instead what is likely to happen is that the next developer that needs the function will create another version of the function and pop it into that or another utility package and eventually you end up with an unmanageable pile of odds and ends in the code base.

Instead, the developer needs to take the time to think about the problem they are trying to solve from an abstract point of view.  What is it that you are trying to do? Never mind how you intend to do it.  If you are parsing data, think about a parsing architecture, ignore the details initially and then see if you have access to someone else’s wheel that they’ve already invented.  Moving from how to what is the way to re-use code.  If you need to make your own, then build it in the abstract and put it in its own domain that can be expanded and re-used.

I vote for a complete ban on any package named ‘util’ in favor of software that is written for a specific problem domain.  If you have static analysis in your build process, I recommend a rule to root it out and eliminate it…you’ll have cleaner code.

No comments: