simulation of static class in java

Question

What do you think of the following way to simulate a static class in java? You can add non static methods but you wouldn't be able to call them.

 /**
  * Utility class: this class contains only static methods and behaves as a static class.
  */
 // ... prevent instantiation with abstract keyword
 public abstract class Utilities
    {
        // ... prevent inheritance with private constructor
        private Utilities() {}

        // ... all your static methods here
        public static Person convert(String foo) {...}
    }

Answer 1

My FindBugs plugin suggests rather final class instead of abstract class. And I use that in my project. It seems to be a widespread idiom if it became a rule that is checked by FindBugs.

Answer 2

i would say, if you habe already a private constructor

private Utilities() {}

the abstract keyword is not neccessary. rather make it final.

the difference to your version is marginal, for any practical means.

Answer 3

That is the usual way. However, there is not need for the abstract keyword. Using a private constructor is sufficient because

• it prevents the creation of objects (from outside the class)
• it prevents inheritance

The abstract keyword suggests the user that users of the class might implemented the class what is not the case here.

Answer 4

I prefer making such classes final, but not abstract. Though it is just a matter of personal style.

By the way, I suppose it is still possible to call its instance methods if you put some energies. E.g. one can try using objenesis to create instance of class.

Answer 5

My suggestion is: prevent incorrect use (i.e. instantiation) by placing javadocs

Isn't that simpler? I think your teammates are able to read ;)

Answer 6

I'll have to agree with those above. Use "final" instead of "abstract". Remember, words like "final" and "abstract" are as much a means of communicating with your fellow programmers as they are instructions to the machine. Abstract implies that there will be descendant classes later, whereas final decidedly means that you will not, save through refactoring, see anything descended of this class (which is your intended meaning).

Further, in most standards I've seen, and consistently in my company, it is considered best practice to make the abstract class something which is specifically left unused, save as a parent of other classes. "Abstract" is treated as "blueprint" or "general structure", you would never drive an "abstract" car. On the other hand, final classes are instantiated perpetually, especially with Factory patterns.

Answer 7

Item 4 in Effective Java (a very... effective book) says:

// Noninstantiable utility class
public final class Utility {

    private Utility() {
        throw new AssertionError();
    }
}

because the explicit costructor is private:

• you cannot instantiate it
• you cannot extend it (as if it was declared as final)

The AssertionError isn't required but it provides another small benefit: it prevents that the costructior is accidentally invoked from within the class.

You can also create a specific annotation, like @BagOfFunction, and annotate your class:

@BagOfFunctions
public final class Utility {

    private Utility() {
        throw new AssertionError();
    }
}

basically you trade a comment for a self-documenting annotation.