Creational Patterns
•Creational Design Patterns are concerned with the way
in which objects are created.
•They reduce complexities and instability by creating
objects in a controlled manner.
•The new operator is often considered harmful as it
scatters objects all over the application.
•Over time it can become challenging to change an
implementation because classes become tightly
coupled.
•Creational Design Patterns address this issue by
decoupling the client entirely from the actual
initialization process.
Singleton
Purpose
Ensures that only one instance of a class is allowed within a system.
Singleton
Use When
•Exactly one instance of a class is required.
•Controlled access to a single object is necessary.
Factory Method
Purpose
Exposes a method for creating objects, allowing subclasses to
control the actual creation process.
Factory Method
Use When
•A class will not know what classes it will be required to create.
•Subclasses may specify what objects should be created.
•Parent classes wish to defer creation to their subclasses.
Abstract Factory
Purpose
Provide an interface that delegates creation calls to one or
more concrete classes to deliver specific objects.
Abstract Factory
Use When
•The creation of objects should be independent of the system utilizing
them.
•Systems should be capable of using multiple families of objects.
•Families of objects must be used together.
•Libraries must be published without exposing implementation details.
•Concrete classes should be decoupled from clients.
Builder
Purpose
Allows for the dynamic creation of objects based upon easily
interchangeable algorithms
Builder
Use When
•Object creation algorithms should be decoupled from the system
•Multiple representations of creation algorithms are required
•The addition of new creation functionality without changing the
core code is necessary.
•Runtime control over the creation process is required.
Prototype
Purpose
Create objects based upon a template of an existing objects
through cloning.
Prototype
Use When
•Composition, creation, and representation of objects should be decoupled
from a system.
•Classes to be created are specified at runtime.
•A limited number of state combinations exist in an object.
•Objects or object structures are required that are identical or closely
resemble other existing objects or object structures.
•The initial creation of each object is an expensive operation.
Object Pool
•Object pool is a set of initialized and ready-to-
use objects.
•When the system needs an object, it is not
created but taken from the pool.
•When the object is no longer needed, it is not
destroyed but returned to the pool.
Object Pool
If there are no free objects in the pool, one of
three strategies is possible:
•Pool expansion.
•Refuse to create an object, emergency stop.
•In case of a multitasking system, you can wait
until one of the objects is free.
Lazy Initialization
•A resource-intensive operation (object
creation, value calculation) is performed
immediately before its result is used.
•Thus, initialization is performed "on demand"
rather than in advance.
Lazy Initialization
•A special case of lazy initialization is the
creation of an object at the moment it is
accessed
•It is usually used in combination with such
patterns as Factory method, Singleton and
Proxy