Util Classes Must Die ~ Don't Call Us - We'll Call You

Tuesday, June 9, 2009

Util Classes Must Die

Using a lot of static methods in utils classes will make your application procedural rather than object oriented.

Util classes cause problems with / violates:

* OO in general: Code is not object oriented
* Testability: Static is hard to test
* Inheritance: You can not extend a helper class
* Polymorphism: Helper class can not derive from an interface / base class
* Cohesion: Several responsiblilties in a class breaks the single responsibility principle
* Encapsulation: Helper methods are procedures

Anti-Patterns and Worst Practices – Utils Class

Chris Missal blogs about Anti-Patterns and Worst-Practices, and mentions the utils class as an indicator of lazyness and lack of domain knowledge:
[...] know that there’s probably a better way. Since the problem I see with Utility classes is that they’re usually just a collection of a whole bunch of stuff that doesn’t really belong together, they probably exist for common reasons.

Are Helper Classes Evil?

Nick Malik has written two articles about the subject, and calls the helper classes an extraordinarily bad idea that should be avoided most of the time. Malik shows how helper classes breaks completely with object orientation (encapsulation, behavior) and several OO pronciples.
[-}the notion of functional decomposition is so easy that we drop to it when we come across an algorithm that doesn't seem to "fit" into our neat little object tree, and rather than understand the needs, analyze where we can get the best use of the technology, and place the method accordingly, we just toss it into a helper class. And that, my friends, is laziness.
What about making reusable code? Here's what Nick has to say about it:
The largest reusable code base that all your developers are already using is the .Net Framework. The vast majority of the framework uses instantiated classes, not static helper classes (there are exceptions, unfortunately). So, the need for reuse is NOT a good argument for helper classes.

Helper Classes Are Evil

Eric Lee from Microsoft Game Stuidos takes a similar stand against the helpers in his blogpost Helper Classes Are Evil:
I very much dislike them in an OOP design because inevitably they becomes a dumping ground for all kinds of things that don’t relate to each other at all in the problem domain. It’s an attractive nuisance, to use a legal term. [-] a real adherence to OOP means that you’ll have lots and lots of small, single-purpose classes.
Next time you're tempted to put code into a helper class, take a step back and think for a second. Will this code violate OO and OO principles? Probably. What does the helper methods do? Can you design this so that the code is placed in a separate class with data and behavior? Don't be lazy. Try to understand the problem domain and come up with an object oriented solution rather than a lazy, procedural one.

So, must helper classes die? Let me paraphrase Nick:
I don't believe that software practices qualify in the moral sphere, so there is no such thing as evil code.

No comments:

Post a Comment