Creational pattern explained

A creational pattern is a software design pattern for creating objects in a manner suitable to a particular situation. As object creation that is otherwise available (i.e. via the programming language) can sometimes result in design limitations, a custom mechanism for creation can provide for better design. A creational pattern aims to separate a system from how its objects are created, composed, and represented. They increase the system's flexibility in terms of the what, who, how, and when of object creation.^[1]

A creational pattern encapsulates two main aspects. One is encapsulating knowledge about which concrete classes the system uses. Another is hiding how instances of these concrete classes are created and combined.^[2]

Creational design patterns are categorized into object-creational patterns and class-creational patterns. Object-creational patterns defer part of its object creation to another object, while class-creational patterns defer its object creation to subclasses.^[3]

Usage

As modern software engineering depends more on object composition than class inheritance, emphasis shifts away from hard-coding behaviors toward defining a smaller set of basic behaviors that can be composed into more complex ones.^[4] Hard-coding behaviors are inflexible because they require overriding or re-implementing the whole thing in order to change parts of the design. Additionally, hard-coding does not promote reuse and makes it difficult to keep track of errors. For these reasons, creational patterns are more useful than hard-coding behaviors. Creational patterns make design become more flexible. They provide different ways to remove explicit references in the concrete classes from the code that needs to instantiate them.^[5] In other words, they create independency for objects and classes.

Consider applying creational patterns when:

• A system should be independent of how its objects and products are created.
• A set of related objects is designed to be used together.
• Hiding the implementations of a class library or product, revealing only their interfaces.
• Constructing different representation of independent complex objects.
• A class wants its subclass to implement the object it creates.
• The class instantiations are specified at run-time.
• There must be a single instance and client can access this instance at all times.
• Instance should be extensible without being modified.

Structure

Below is a simple class diagram that most creational patterns have in common. Note that different creational patterns require additional and different participated classes.

Participants:

• Creator: Declares object interface. Returns object.
• ConcreteCreator: Implements object's interface.

Examples

Some examples of creational design patterns include:

Abstract factory pattern: a class requests the objects it requires from a factory object instead of creating the objects directly.^[6]

Factory method pattern: centralize creation of an object of a specific type choosing one of several implementations.^[7]

Builder pattern: separate the construction of a complex object from its representation so that the same construction process can create different representations.

Dependency injection pattern: a class accepts the objects it requires from an injector instead of creating the objects directly

Lazy initialization pattern: tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.

Object pool pattern: avoid expensive acquisition and release of resources by recycling objects that are no longer in use.

Prototype pattern: used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects.

Singleton pattern: restrict instantiation of a class to one object.^[8]

See also

• Constructor
• Behavioral pattern
• Concurrency pattern
• Structural pattern

Notes and References

1. Book: Judith, Bishop. C# 3.0 Design Patterns. 2007. O'Reilly Media. California. 978-0-596-52773-0. 336. 2015-05-22.
2. Book: Design Patterns. 1995. Addison-Wesley. Massachusetts. 978-0-201-63361-0. Gamma. Erich. Helm. Richard. Johnson. Ralph. Vlissides. John. 81. 2015-05-22.
3. Book: Design Patterns. 1995. Addison-Wesley. Massachusetts. 978-0-201-63361-0. Gamma. Erich. Helm. Richard. Johnson. Ralph. Vlissides. John. 2015-05-22.
4. Book: Design Patterns. 1995. Addison-Wesley. Massachusetts. 978-0-201-63361-0. Gamma. Erich. Helm. Richard. Johnson. Ralph. Vlissides. John. 84. 2015-05-22.
5. Book: Design Patterns. 1995. Addison-Wesley. Massachusetts. 978-0-201-63361-0. Gamma. Erich. Helm. Richard. Johnson. Ralph. Vlissides. John. 85. 2015-05-22.
6. Book: Freeman. Eric. Freeman. Elisabeth. Sierra. Kathy. Bates. Bert. Hendrickson. Mike. Loukides. Mike. 2004. Head First Design Patterns. O'Reilly Media. California. 978-0-596-00712-6. 156. 2015-05-22.
7. Book: Freeman. Eric. Freeman. Elisabeth. Sierra. Kathy. Bates. Bert. Hendrickson. Mike. Loukides. Mike. 2004. Head First Design Patterns. O'Reilly Media. California. 978-0-596-00712-6. 134. 2015-05-22.
8. Book: Freeman. Eric. Freeman. Elisabeth. Sierra. Kathy. Bates. Bert. Hendrickson. Mike. Loukides. Mike. 2004. Head First Design Patterns. O'Reilly Media. California. 978-0-596-00712-6. 177. 2015-05-22.