Item1 - Consider static factory methods instead of constructors

One advantage of static factory methods is that, unlike constructors, they have names.

A static factory with a well-chosen name is easier to use and the resulting client code easier to read. For example, the constructor BigInteger(int, int, Random), which returns a BigInteger that is probably prime, would have been better expressed as a static factory method named BigInteger.probablePrime.

A class can have only a single constructor with a given signature. Programmers get around this restriction by providing two constructors whose parameter lists differ only in the order of their parameter types. The user will never be able to remember which constructor is which and will end up calling the wrong one by mistake. Static factory methods have names, so they don’t share the restriction.

A second advantage of static factory methods is that, unlike constructors, they are not required to create a new object each time they’re invoked.

This allows immutable classes to use pre-constructed instances, or to cache instances as they’re constructed, and dispense them repeatedly to avoid creating unnecessary duplicate objects. It can greatly improve performance if equivalent objects are requested often, especially if they are expensive to create.

Boolean.valueOf(boolean) : it never creates an object.

public static Boolean valueOf(boolean b) {
    return b ? Boolean.TRUE : Boolean.FALSE;
}

The ability of static factory methods to return the same object from repeated invocations allows classes to maintain strict control over what instances exist at any time. Classes that do this are said to be instance-controlled: It allows a class to guarantee that it is a singleton or noninstantiable. Also, it allows an immutable value class to make the guarantee that no two equal instances exist: a.equals(b) if and only if a == b.

A third advantage of static factory methods is that, unlike constructors, they can return an object of any subtype of their return type.

This gives you great flexibility in choosing the class of the returned object.

One application of this flexibility is that an API can return objects without making their classes public. Hiding implementation classes in this fashion leads to a very compact API. This technique lends itself to interface-based frameworks , where interfaces provide natural return types for static factory methods.

Prior to Java 8, interfaces couldn’t have static methods.

For example, the Java Collections Framework has forty-five utility implementations of its interfaces, providing unmodifiable collections, synchronized collections, and the like. Nearly all of these implementations are exported via static factory methods in one noninstantiable class (java.util.Collections). The classes of the returned objects are all nonpublic.

Note, it may still be necessary to put the bulk of the implementation code behind these static methods in a separate package-private class. This is because Java 8 requires all static members of an interface to be public. Java 9 allows private static methods, but static fields and static member classes are still required to be public.

A fourth advantage of static factories is that the class of the returned object can vary from call to call as a function of the input parameters.

The class of the returned object can also vary from release to release.

The EnumSet class has no public constructors, only static factories. In the OpenJDK implementation, they return an instance of one of two subclasses, depending on the size of the underlying enum type: if it has sixty-four or fewer elements, the static factories return a RegularEnumSet instance, which is backed by a single long; if the enum type has sixty-five or more elements, the factories return a JumboEnumSet instance, backed by a long array.

A future release could add a third or fourth implementation of EnumSet if it proved beneficial for performance.

A fifth advantage of static factories is that the class of the returned object need not exist when the class containing the method is written.

Such flexible static factory methods form the basis of service provider frameworks, like the Java Database Connectivity API (JDBC). A service provider framework is a system in which providers implement a service, and the system makes the implementations available to clients, decoupling the clients from the implementations.

There are three essential components in a service provider framework: a service interface, which represents an implementation; a provider registration API, which providers use to register implementations; and a service access API, which clients use to obtain instances of the service. The service access API may allow clients to specify criteria for choosing an implementation. In the absence of such criteria, the API returns an instance of a default implementation, or allows the client to cycle through all available implementations. The service access API is the flexible static factory that forms the basis of the service provider framework.

An optional fourth component of a service provider framework is a service provider interface, which describes a factory object that produces instances of the service interface. In the absence of a service provider interface, implementations must be instantiated reflectively . In the case of JDBC, Connection plays the part of the service interface, DriverManager.registerDriver is the provider registration API, DriverManager.getConnection is the service access API, and Driver is the service provider interface.

There are many variants of the service provider framework pattern. For example, the service access API can return a richer service interface to clients than the one furnished by providers. Since Java 6, the platform includes a general-purpose service provider framework, java.util.ServiceLoader, so you needn’t, and generally shouldn’t, write your own. JDBC doesn’t use ServiceLoader, as the former predates the latter.

The main limitation of providing only static factory methods is that classes without public or protected constructors cannot be subclassed.

For example, it is impossible to subclass any of the convenience implementation classes in the Collections Framework.

A second shortcoming of static factory methods is that they are hard for programmers to find.

They do not stand out in API documentation in the way that constructors do, so it can be difficult to figure out how to instantiate a class that provides static factory methods instead of constructors.

Here are some common names for static factory methods.

? from—A type-conversion method that takes a single parameter and returns a corresponding instance of this type, for example:

Date d = Date.from(instant);

? of—An aggregation method that takes multiple parameters and returns an instance of this type that incorporates them, for example:

Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);

? valueOf—A more verbose alternative to from and of, for example:

BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);

? instance or getInstance—Returns an instance that is described by its parameters (if any) but cannot be said to have the same value, for example:

StackWalker luke = StackWalker.getInstance(options);

? create or newInstance—Like instance or getInstance, except that the method guarantees that each call returns a new instance, for example:

Object newArray = Array.newInstance(classObject, arrayLen);

? getType—Like getInstance, but used if the factory method is in a different class. Type is the type of object returned by the factory method, for example:

FileStore fs = Files.getFileStore(path);

? newType—Like newInstance, but used if the factory method is in a different class. Type is the type of object returned by the factory method, for example:

BufferedReader br = Files.newBufferedReader(path);

? type—A concise alternative to getType and newType, for example:

List<Complaint> litany = Collections.list(legacyLitany);