Final class with private constructor, what is the design principle

Question

I was recently going through one of the Netflix open source project

There I found use of both final class along with private constructor. I fully aware that

1. final is to avoid inheritance
2. private is to disallow instantiation

But m just curious to know why they are both used together. Although methods are static, so we can use them without instantiation but still eager to know design principle behind it.

Answer 1

With this code you will have this features

• Not allow anyone subclass (extends) your class
• Not allow instantiating your class
• Making a variables or classes final increase the performance (not much, but it does and used as common practice in big projects will make a difference)

In this case I can't see a singleton pattern to get an instance, so, IMHO, you're looking to a helper/util class in the Netflix API, where the developer team used some standard practices to ensure users use their classes in the correct way:

StaticFinalClassExample.methodYouWantToCall();

Also, looking at the class you linked:

/**
 * This class consists exclusively of static methods that help verify the compliance of OP1A-conformant....
 */

And:

//to prevent instantiation
private IMFConstraints()
{}

---

ADD ON:

If you want further info, take a look at Item 4 from Joshua Bloch's Effective Java (2nd Edition):

Item 4: Enforce noninstantiability with a private constructor

Occasionally you’ll want to write a class that is just a grouping of static methods and static fields. Such classes have acquired a bad reputation because some people abuse them to avoid thinking in terms of objects, but they do have valid uses.

• They can be used to group related methods on primitive values or arrays, in the manner of java.lang.Math or java.util.Arrays.
• They can also be used to group static methods, including factory methods (Item 1), for objects that implement a particular interface, in the manner of java.util.Collections.
• Lastly, they can be used to group methods on a final class, instead of extending the class.

Such utility classes were not designed to be instantiated: an instance would be nonsensical. In the absence of explicit constructors, however, the compiler provides a public, parameterless default constructor. To a user, this constructor is indistinguishable from any other. It is not uncommon to see unintentionally instantiable classes in published APIs.

Attempting to enforce noninstantiability by making a class abstract does not work. The class can be subclassed and the subclass instantiated. Furthermore, it misleads the user into thinking the class was designed for inheritance (Item 17).

There is, however, a simple idiom to ensure noninstantiability. A default constructor is generated only if a class contains no explicit constructors, so a class can be made noninstantiable by including a private constructor.