Should a utility class be static? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

If I have to design a Utility class( such as ByteUtils or StreamUtils or StringUtils), what is the best design choice for them.

• Should they be static classes (as I won't have any states to store)
• Should they be n开发者_如何学Goon-static classes ( so that if the objects are not used, they will be gc'd)

PS: By static class, I meant a class with static methods(and not the inner static class)

Please give advice on design choices for this ?

---

My utility classes look like this:

// final, because it's not supposed to be subclassed
public final class FooUtil {

    // private constructor to avoid unnecessary instantiation of the class
    private FooUtil() {
    }

    public static int doSomethingUseful() {
    }

    // ...
}

Note that, although this makes the utility methods easily testable, and easily accessible from the outside, it also makes the classes using them hard to unit-test, because it's not easy to mock these utility methods. Having too many of such utility classes can be a sign of a lack of OO design (procedural programming), and can really make the code hard to test.

If you're using a dependency injection framework (Spring, Guice, whatever), it might be a good idea to just make the utility class instantiatable, with non-static methods, and make it an injectable singleton. This way, classes using these utility methods can be tested by mocking the utility object.

---

If it is a general purpose utility, static is IMO better. You stated that you will not have any states to store, so I don't see why should you make it non-static. Declaring it to be static will save memory too.

---

Just because something can be static, doesn't mean it should be static.

There is another consideration to all this: mocking. It's harder to mock static methods in your tests than it is to mock the behaviour of an instance of a class.

Talk of unnecessary heap allocations and GCing of objects smacks of premature optimisation to me. The JVM will do a pretty good job at optimising away this sort of issue.

---

The simplest way to define a Utility class is as an enum with no instances

public enum Utility {;
     public static int utilityMethod(int x) { /* ... */ }
}

A utility class shouldn't have any state or have minimal state so you shouldn't worrying about GCs.

You can have other stateful classes for specific purposes like Builder, Factory, you can create the object as desired and discard it when you have finished.

---

Its good to make the class as non-static with a private constructor:

• if we make the class static then class will be loaded when the application is deployed, if it is non-static then the class will be loaded when there is a call to one of its static methods
• creating a private constructor will avoid instantiating the class

---

Usually utility classes contain static methods and no attributes, this approach makes it easier to use their methods without instantiating the class. Hope this helps.

---

Well, if you have no state to store then there is nothing to GC, so I would go with static, that way you avoid any unnecessary heap allocations and GC.

---

If you can make them static, then definitely do so!

In other words, if they don't have state, they should be static.

---

Pure utility classes should usually be static. When you have a class with well-defined input and output, no side effects and no state, then by definition it should be a static class.

In general, don't add complexity (dependency injection in this case) before it's necessary and there's a benefit in doing it.

---

Nobody here mention that static utility methods are not extensible. You cannot override them. You cannot take advantage of OOP (particularly polymorphysm, which is most powerful feature of OOP). That leads to code duplication.

P.S. I found this article very helpful. http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html