Creational pattern: Difference between revisions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
imported>Blazing Arrow
Slightly modified wording.
 
imported>Stevebroshar
Match text to title
 
Line 1: Line 1:
{{short description|Software design pattern dealing with object creation}}
{{short description| Software design pattern for object creation}}


In [[software engineering]], '''creational design patterns''' are [[design pattern (computer science)|design patterns]] that deal with [[object lifetime|object creation]] mechanisms, trying to create [[Object (computer science)|objects]] in a manner suitable to the situation. The basic form of object creation could result in design problems or in added complexity to the design due to inflexibility in the creation procedures. Creational design patterns solve this problem by somehow controlling this object creation.
A '''creational pattern''' is a [[software design pattern]] for creating [[Object (computer science)|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 [[software design| 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>


==Overview==
A creational pattern encapsulates two main aspects. One is encapsulating knowledge about which concrete [[Class (programming)|classes]] the system uses. Another is hiding how [[Instance (computer science)|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 composed of two dominant ideas. One is encapsulating knowledge about which concrete [[Class (computer programming)|classes]] the system uses. Another is hiding how [[Instance (computer science)|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 further categorized into object-creational patterns and class-creational patterns, where object-creational patterns deal with object creation and class-creational patterns deal with class-instantiation. In greater details, 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>
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>
 
Five well-known design patterns that are parts of creational patterns are the
* [[abstract factory pattern]], which provides an interface for creating related or dependent objects without specifying the objects' concrete classes.<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>
* [[builder pattern]],  which separates the construction of a complex object from its representation so that the same construction process can create different representations.
* [[factory method pattern]], which allows a class to defer instantiation to subclasses.<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>
* [[prototype pattern]], which specifies the kind of object to create using a prototypical instance, and creates new objects by cloning this prototype.
* [[singleton pattern]], which ensures that a class only has one instance, and provides a global point of access to it.<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>
 
==Definition==
The creational patterns aim 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>


==Usage==
==Usage==
Line 46: Line 31:
Some examples of creational design patterns include:
Some examples of creational design patterns include:


* [[Abstract factory pattern|Abstract Factory pattern]]: a class requests the objects it requires from a factory object instead of creating the objects directly
; [[Abstract factory pattern]]: a class requests the objects it requires from a factory object instead of creating the objects directly.<ref>
* [[Factory method pattern]]: centralize creation of an object of a specific type choosing one of several implementations
{{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>
* [[Builder pattern]]: separate the construction of a complex object from its representation so that the same construction process can create different representations
; [[Factory method pattern]]: centralize creation of an object of a specific type choosing one of several implementations.<ref>
* [[Dependency injection|Dependency Injection pattern]]: a class accepts the objects it requires from an injector instead of creating the objects directly
{{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>
* [[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
; [[Builder pattern]]: separate the construction of a complex object from its representation so that the same construction process can create different representations.
* [[Object pool pattern]]: avoid expensive acquisition and release of resources by recycling objects that are no longer in use
; [[Dependency injection| Dependency injection pattern]]: a class accepts the objects it requires from an injector instead of creating the objects directly
* [[Prototype pattern]]: used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects
; [[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.
* [[Singleton pattern]]: restrict instantiation of a class to one object
; [[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>


==See also==
==See also==

Latest revision as of 15:35, 15 December 2025

Template:Short description

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

File:Creational Pattern Simple Structure.png
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.[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

References

<templatestyles src="Reflist/styles.css" />

  1. Script error: No such module "citation/CS1".
  2. Script error: No such module "citation/CS1".
  3. Script error: No such module "citation/CS1".
  4. Script error: No such module "citation/CS1".
  5. Script error: No such module "citation/CS1".
  6. Script error: No such module "citation/CS1".
  7. Script error: No such module "citation/CS1".
  8. Script error: No such module "citation/CS1".

Script error: No such module "Check for unknown parameters".

Template:Design Patterns patterns