Utility classes are evil? [closed]

Question

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?

Answer 1

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();
}  

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

Utility classes are not always evil. But they should only contain the methods that are common across a wide range of functionality. If there are methods that are only usable among a limited number of classes, consider creating a abstract class as a common parent and put the methods in it.