Where is utility class

I would consider utility classes as a bad practice because they tend, after a while, to contain a lot of junk and are rarely reorganized and maintained. As an example, I worked on an already started application a few weeks ago in which I found one of these classes. But then, if someone looks at the overview of a class seeing a bunch of static methods, then what is the point of instantiating the class?

If you just want to use a static method, why would you ever instantiate its class? It looks obvious that there is nothing to instantiate about that class because it only has static stuff in it. So what are we trying to protect ourselves from, seriously?

Trying to be overly defensive about this feels like not trusting your developers having enough intelligence at all. Which sounds like a company having serious problems then. There are millions of ways code can go wrong without common sense, and I would rather spend my time on doing things that are actually worth doing.

The whole show starts only after we call addAll. All lines in the second snippet, except the last one, instantiate and compose smaller objects into bigger ones. Besides that, it is obvious that the second script runs in O 1 space, while the first one executes in O n. This is the consequence of our procedural approach to data in the first script.

Please, use syntax highlighting in your comments, to make them more readable. JavaScript is disabled in your browser, that's why you can't see comments under this post. Procedural Example Say, for instance, you want to read a text file, split it into lines, trim every line and then save the results in another file.

In case of setters, the behavior can be changed even at runtime. This is not possible when using Utility Classes. When all the dependencies are provided externally, the class does not suffer from "dependency hiding".

From the class's public interface it is obvious, which dependencies it requires to proper function. It is still not a violation of encapsulation as the class just clearly states its collaborators, but does not reveal the way of using them to perform its core purpose. Many frameworks depend on dynamic proxies for adding additional functionality to class instances.

Consumers are provided with a proxy instead of a regular instance. It has the required type but provides some other behavior on top of that. For example, you can add method-level security restricting access to methods unless the user has a specific role. Another example can be adding AOP logging to method calls which is not a core responsibility of the class but rather cross-cutting concern and should be managed externally. Such behavior cannot be added to classes using dynamic proxies.

As already mentioned, a class using Utility Class is responsible not only for its original role, but also for obtaining its dependencies. Another problem is that existing Utility Classes have tendencies to rot.

Usually, such classes are created from a code, which has no better or proper place to be. Over time, if you are not very strict, these classes tend to accumulate more and more code, which may be not so related to the original methods. The class would lose its original single responsibility and become a jack-of-all-trades.