?

?

This post is a summary of this artical and this one.

What's Utility Classes

A utility class is a class filled with static methods. It is usually used to isolate a useful algorithm.
>StringUtils, IOUtils, FileUtils from Apache Commons; Iterables and Iterators from Guava, and Files from JDK7 are perfect examples of utility classes.

Why Utility Classes

If you have two classes A and B, and have a method f() that both must use, then the most naive approach is to repeat the function as a method in both classes. However, this violates the Don't repeat yourself (DRY) approach to programming.

The most natural solution is inheritance, but it's not always beneficial for A and B to be subclasses of some parent class. In my case, A was already a subclass of another class, while B was not. There was no way to make A and B subclasses of a parent class without breaking that other relationship.

The alternative is to define the utility class: a public static class that sits in the global namespace, awaiting anyone to borrow them.

They are not bad in themselves, but they do imply relationships between your data that are not explicitly defined. Also, if your static class has any static variables, then A and B never really know what they're getting into when they use it.

Disadvantage

However, in an object-oriented world, utility classes are considered a very bad practice.
The use of utility classes to be an antipattern. More specifically, it violates common design principles:

Single Responsibility Principle

A class should have one and only one reason to change

You can design utility classes where all of the methods related to a single set of responsibilities. That is entirely possible. Therefore, I would note that this principle does not conflict with the notion of utility classes at all.
That said, I've often seen helper classes that violate this principle. They become catch all classes (or God Classes) that contain any method that the developer can't find another place for. (e.g. a class containing a helper method for URL encoding, a method for looking up a password, and a method for writing an update to the config file... This class would violate the Single Responsibility Principle).

Liskov Substitution Principle

Derived classes must be substitutable for their base classes

This is kind of a no-op in that a utility class cannot have a derived class. OK. Does that mean that utility classes violate LSP? I'd say not. A helper class looses the advantages of OO completely, an in that sense, LSP doesn't matter... but it doesn't violate it.

Interface Segregation Principle

Class interfaces should be fine-grained and client specific

another no-op. Since utility classes do not derive from an interface, it is difficult to apply this principle with any degree of seperation from the Single Responsibility Principle.

The Open Closed Principle

classes should be open for extension and closed for modification

You cannot extend a utility class. Since all methods are static, you cannot derive anything that extends from it. In addition, the code that uses it doesn't create an object, so there is no way to create a child object that modifies any of the algorithms in a utility class. They are all unchangable.