Utility classes are evil?

0 votes
asked Jul 27, 2010 by hvgotcodes

I saw this thread

If a "Utilities" class is evil, where do I put my generic code?

and thought why are utility classes evil?

Lets say I have a domain model that is dozens of classes deep. I need to be able to xml-ify instances. Do I make a toXml method on the parent? Do I make a MyDomainXmlUtility.toXml helper class? This is a case where the business need spans the entire domain model -- does it really belong as an instance method? What about if there are a bunch of auxiliary methods on the xml functionality of the application?

14 Answers

0 votes
answered Jul 27, 2010 by stephen-c

I think that the general consensus is that utility classes are not evil per se. You just need to use them judiciously:

  • Design the static utility methods to be general and reusable. Make sure that they are stateless; i.e. no static variables.

  • If you have lots of utility methods, partition them into classes in a way that will make it easy for developers to find them.

  • Don't use utility classes where static or instance methods in a domain class would be a better solution. For example, consider if methods in an abstract base class or an instantiable helper class would be a better solution.

  • For Java 8 onwards, "default methods" in an interface may be a better option than utility classes.


The other way to look at this Question is to observe that in the quoted Question, "If utility classes are "evil"" is a strawman argument. Its like me asking:

"If pigs can fly, should I carry an umbrella?".

In the above question I am not actually saying that pigs can fly ... or that I agree with the proposition that they could fly.

Typical "xyz is evil" statements are rhetorical devices that are intended to make you think by posing an extreme viewpoint. They are rarely (if ever) intended as statements of literal fact.

0 votes
answered Jul 27, 2010 by alain-odea

Utility classes are problematic because they fail to group responsibilities with the data that supports them.

They are however extremely useful and I build them all the time as either permanent structures or as stepping stones during a more thorough refactor.

From a Clean Code perspective utility classes violate the Single Responsibility and the Open-Closed Principle. They have lots of reasons to change and are by design not extensible. They really should only exist during refactoring as intermediate cruft.

0 votes
answered Jul 27, 2010 by mdma

It's very easy to brand something a utility simply because the designer couldn't think of an appropriate place to put the code. There are often few true "utilities".

As a rule of thumb, I usually keep code in the package where it is first used, and then only refactor to a more generic place if I find that later it really is needed elsewhere. The only exception is if I already have a package that performs similar/related functionality, and the code best fits there.

0 votes
answered Jul 27, 2010 by thomas-owens

Utility classes aren't exactly evil, but they can violate the principles that compose a good object-oriented design. In a good object-oriented design, most classes should represent a single thing and all of it's attributes and operations. If you are operating on a thing, that method should probably be a member of that thing.

However, there are times when you can use utility classes to group a number of methods together - an example being the java.util.Collections class which provides a number of utilities that can be used on any Java Collection. These aren't specific to one particular type of Collection, but instead implement algorithms that can be used on any Collection.

Really, what you need to do is think about your design and determine where it makes the most sense to put the methods. Usually, it's as operations inside of a class. However, sometimes, it is indeed as a utility class. When you do use a utility class, however, don't just throw random methods into it - organize the methods by purpose and functionality.

0 votes
answered Jul 27, 2010 by enno-shioji

I suppose it starts to become evil when

1) It gets too big (just group them into meaningful categories in this case).
2) Methods that should not be static methods are present

But as long as these conditions are not met, I think they are very useful.

0 votes
answered Jul 27, 2010 by larry-watanabe

Utility classes are bad because they mean you were too lazy to think up a better name for the class :)

That being said, I am lazy. Sometimes you just need to get the job done and your mind's a blank .. that's when "Utility" classes start creeping in.

0 votes
answered Jul 27, 2010 by seand

Utility classes containing stateless static methods can be useful. These are often very easy to unit test.

0 votes
answered Jul 27, 2010 by mr-white

When I can't add a method to a class (say, Account is locked against changes by Jr. Developers), I just add a few static methods to my Utilities class like so:

public static int method01_Account(Object o, String... args) {
    Account acc = (Account)o;
    ...
    return acc.getInt();
}  
0 votes
answered Jul 10, 2015 by yegor256

Utility classes are are evil, even though they may look very useful and convenient. This post explains it in more details: http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html If you're writing true object-oriented software you should use objects instead, no matter how many of them you will create.

0 votes
answered Jul 9, 2016 by the-unholy-programme

I don't entirely agree that utility classes are evil.

While a utility class may violate OO principals in some ways, they aren't always bad.

For example, imagine you want a function that will cleans a string of all substrings matching value x.

stl c++ (as of now) doesn't directly support this.

You could create a polymorphic extension of std::string.

But the problem is, do you really want EVERY string you use in your project to be your extended string class?

There are times when OO doesn't really make sense, and this is one of them. We want our program to be compatible with other programs, so we will stick with std::string and create a class StringUtil_ (or something).

I'd say its best if you stick with one util per class. I'd say it's silly to have one util for all classes or many utils for one class.

Welcome to Q&A, where you can ask questions and receive answers from other members of the community.
Website Online Counter

...