Creational pattern: Difference between revisions
imported>Blazing Arrow Slightly modified wording. |
imported>Stevebroshar Match text to title |
||
| Line 1: | Line 1: | ||
{{short description|Software design pattern | {{short description| Software design pattern for 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> | |||
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 | 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== | ==Usage== | ||
| Line 46: | Line 31: | ||
Some examples of creational design patterns include: | 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| 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> | |||
==See also== | ==See also== | ||
Latest revision as of 15:35, 15 December 2025
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
References
<templatestyles src="Reflist/styles.css" />
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
Script error: No such module "Check for unknown parameters".