Item 1. Consider static factory methods instead of constructors.
Advantages:
- One advantage of static factory methods is that, unlike constructors, they have names.
- They are not required to create new objects each time they are invoked. This allows immutable classes to use preconstructed instances, or to cache instances as they are constructed.
Help to increase performance. - Another advantage is that, unlike constructors, they can return an object of any subtype of their return type. This gives you flexibility in choosing the class of the returned object.
- They reduce the verbosity of creating parameterized type instances.
Disadvantages:
- The main disadvantage of providing only static factory methods is that classes without public or protected constructors cannot be subclassed.
- They are not readily distinguishable from other static methods. Also they do not stand out in the API documentation as constructors do.
Item 2. Consider a builder when faced with many constructor parameters.
Static factories and constructors share a limitation: they do not scale well to large numbers of optional parameters.
Alternative one:
Traditionally, programmers have used the telescoping constructor pattern, in which you provide a constructor with only the required parameters, another with a single optional parameter, another with two optional parameters and so on, culminating in a constructor with all the optional parameters.
The telescoping constructor pattern works, but it is hard to write client code when they are many parameters, and harder still to read it.
Alternative two:
JavaBeans pattern, in which you call a parameterless constructor to create the object and then call setter methods to set each required parameter and each optional parameter of interest.
This pattern has none of the disadvantages of the telescoping constructor pattern. Unfortunately, the JavaBeans patter has serious disadvantages of its own. Because construction is split across multiple class, a JavaBean may be in an inconsistent state partway through its construction.
Third alternative (the good one):
Using the Builder pattern which combines the Telescoping pattern and the JavaBeans pattern. Instead of making the desired object directly, the client calls a constructor (or static factory) with all of the required parameters and gets a builder object. Then the client calls setter-like methods on the builder object to set each optional parameter of interest. Finally, the client calls a parameterless build method to generate the object, which is immutable. The builder is a static member class of the class it builds.
The Builder pattern is more verbose than the telescoping constructor pattern, so it should be used only if there are enough parameters, say four or more (but you may want to add parameters in the future).
In summary: The builder pattern is a good choice when designing classes whose constructors or static factories would have more than a handful of parameters.
From Effective Java: http://java.sun.com/docs/books/effective/



Recent Comments