Creational pattern

{{short description| Software design pattern for object creation}}

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.<ref name=CS3DP>{{cite book|last=Judith|first=Bishop|title=C# 3.0 Design Patterns|year=2007|publisher=O'Reilly Media|location=California|isbn=978-0-596-52773-0|page=[https://archive.org/details/c30designpattern0000bish/page/336 336]|access-date=2015-05-22|url=https://archive.org/details/c30designpattern0000bish/page/336}}</ref>

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.<ref>{{cite book|title=Design Patterns|year=1995|publisher=Addison-Wesley|location=Massachusetts|isbn=978-0-201-63361-0|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|page=[https://archive.org/details/designpatternsel00gamm/page/81 81]|access-date=2015-05-22|url=https://archive.org/details/designpatternsel00gamm/page/81}}</ref>

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.<ref>{{cite book|title=Design Patterns|year=1995|publisher=Addison-Wesley|location=Massachusetts|isbn=978-0-201-63361-0|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|access-date=2015-05-22|url=https://archive.org/details/designpatternsel00gamm}}</ref>

==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.<ref>{{cite book|title=Design Patterns|year=1995|publisher=Addison-Wesley|location=Massachusetts|isbn=978-0-201-63361-0|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|page=[https://archive.org/details/designpatternsel00gamm/page/84 84]|access-date=2015-05-22|url=https://archive.org/details/designpatternsel00gamm/page/84}}</ref> 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.<ref>{{cite book|title=Design Patterns|year=1995|publisher=Addison-Wesley|location=Massachusetts|isbn=978-0-201-63361-0|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|page=[https://archive.org/details/designpatternsel00gamm/page/85 85]|access-date=2015-05-22|url=https://archive.org/details/designpatternsel00gamm/page/85}}</ref> 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== thumb|right|220px|Creational Pattern class diagram. 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.<ref> {{cite book|last1=Freeman|first1=Eric|last2=Freeman|first2=Elisabeth|last3=Sierra|first3=Kathy|last4=Bates|first4=Bert|editor-last=Hendrickson|editor-first=Mike|editor2-last=Loukides|editor2-first=Mike|year=2004|title=Head First Design Patterns|publisher=O'Reilly Media|location=California|isbn=978-0-596-00712-6|page=156|access-date=2015-05-22|url=http://shop.oreilly.com/product/9780596007126.do}}</ref> ; Factory method pattern: centralize creation of an object of a specific type choosing one of several implementations.<ref> {{cite book|last1=Freeman|first1=Eric|last2=Freeman|first2=Elisabeth|last3=Sierra|first3=Kathy|last4=Bates|first4=Bert|editor-last=Hendrickson|editor-first=Mike|editor2-last=Loukides|editor2-first=Mike|year=2004|title=Head First Design Patterns|publisher=O'Reilly Media|location=California|isbn=978-0-596-00712-6|page=134|access-date=2015-05-22|url=http://shop.oreilly.com/product/9780596007126.do}}</ref> ; 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.<ref> {{cite book|last1=Freeman|first1=Eric|last2=Freeman|first2=Elisabeth|last3=Sierra|first3=Kathy|last4=Bates|first4=Bert|editor-last=Hendrickson|editor-first=Mike|editor2-last=Loukides|editor2-first=Mike|year=2004|title=Head First Design Patterns|publisher=O'Reilly Media|location=California|isbn=978-0-596-00712-6|page=177|access-date=2015-05-22|url=http://shop.oreilly.com/product/9780596007126.do}}</ref>

==References== {{reflist}}

{{DEFAULTSORT:Creational Pattern}} Category:Software design patterns