Creational patterns

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

• Creates an instance of several families of classes
• Separates object construction from its representation
• Creates an instance of several derived classes
• Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
• A fully initialized instance to be copied or cloned
• A class of which only a single instance can exist

Rules of thumb

1. Sometimes creational patterns are competitors: there are cases when either or could be used profitably. At other times they are complementory: might store a set of from which to clone and return product objects, can use one of the other patterns to implement which components get built. , , and can use in their implementation.
2. , , and define a factory object that’s responsible for knowing and creating the class of product objects, and make it a parameter of the system. has the factory object producing objects of several classes. has the factory object building a complex product incrementally using a correspondingly complex protocol. has the factory object (aka prototype) building a product by copying a prototype object.
3. classes are often implemented with s, but they can also be implemented using .
4. can be used as an alternative to to hide platform-specific classes.
5. focuses on constructing a complex object step by step. emphasizes a family of product objects (either simple or complex). returns the product as a final step, but as far as the is concerned, the product gets returned immediately.
6. is to creation as is to algorithm.
7. often builds a .
8. s are usually called within s.
9. : creation through inheritance. : creation through delegation.
10. Often, designs start out using (less complicated, more customizable, subclasses proliferate) and evolve toward , , or (more flexible, more complex) as the designer discovers where more flexibility is needed.
11. doesn’t require subclassing, but it does require an Initialize operation. requires subclassing, but doesn’t require Initialize.
12. Designs that make heavy use of the and patterns often can benefit from as well.