Chapter 6. Creation While every object-oriented system creates objects or object structures, the creation code is not always free of duplication, simple, intuitive, or as loosely coupled to client code as it could be. The six refactorings in this chapter target design problems in everything from constructors to overly complicated construction logic to unnecessary Singletons [DP]. While these refactorings don't address every creational design problem you'll likely encounter, they do address some of the most common problems. If there are too many constructors on a class, clients will have a difficult time knowing which constructor to call. One solution is to reduce the number of constructors by applying such refactorings as Extract Class [F] or Extract Subclass [F]. If that isn't possible or useful, you can clarify the intention of the constructors by applying Replace Constructors with Creation Methods (57). What is a Creation Method? It is simply a static or nonstatic method that creates and returns an object instance. For this book, I decided to define the Creation Method pattern to help distinguish it from the Factory Method [DP] pattern. A Factory Method is useful for polymorphic creation. Unlike a Creation Method, a Factory Method may not be static and must be implemented by at least two classes, typically a superclass and a subclass. If classes in a hierarchy implement a method similarly, except for an object creation step, you can likely remove duplicate code by first applying Introduce Polymorphic Creation with Factory Method (88). A class that is a Factory is one that implements one or more Creation Methods. If data and/or code used in object creation become sprawled across numerous classes, you'll likely find yourself frequently updating code in numerous places, a sure sign of the smell Solution Sprawl (43). Applying Move Creation Knowledge to Factory (68) will reduce creational sprawl by consolidating creation code and data under a single Factory. Encapsulate Classes with Factory (80) is another useful refactoring that involves the Factory pattern. The two most common motivations for applying this refactoring are (1) to ensure that clients communicate with instances of classes via a common interface and (2) to reduce client knowledge of classes while making instances of the classes accessible via a Factory. To simplify the construction of an object structure, there is no better pattern than Builder [DP]. Encapsulate Composite with Builder (96) shows how a Builder can provide a simpler, less error-prone way to construct a Composite [DP]. The final refactoring in this section is Inline Singleton (114). It was a joy to write this refactoring, for I often encounter Singletons that do not need to exist. This refactoring, which shows you how to remove a Singleton from your code, features advice about Singletons from Ward Cunningham, Kent Beck, and Martin Fowler. | 
