Design Patterns
239 pág.

Design Patterns


DisciplinaEngenharia de Software I5.620 materiais57.328 seguidores
Pré-visualização50 páginas
corej2eepatterns/ Patterns/ ). Sun
Microsystems, Inc.. Retrieved 2012-08-11.
10
Creational Patterns
Creational pattern
In software engineering, creational design patterns are design patterns that deal with object creation mechanisms,
trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design
problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling
this object creation.
Creational design patterns are composed of two dominant ideas. One is encapsulating knowledge about which
concrete classes the system use. Another is hiding how instances of these concrete classes are created and
combined.[1]
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 objection creation to subclasses.[2]
Five well-known design patterns that are parts of creational patterns are the
\u2022 Abstract factory pattern, which provides an interface for creating related or dependent objects without specifying
the objects' concrete classes.[3]
\u2022 Builder pattern, which separates the construction of a complex object from its representation so that the same
construction process can create different representation.
\u2022 Factory method pattern, which allows a class to defer instantiation to subclasses.[4]
\u2022 Prototype pattern, which specifies the kind of object to create using a prototypical instance, and creates new
objects by cloning this prototype.
\u2022 Singleton pattern, which ensures that a class only has one instance, and provides a global point of access to it.[5]
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.[6]
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.[7] 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 is hard 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 (patterns) to remove explicit references in the
concrete classes from the code that needs to instantiate them.[8] In other words, they create independency for objects
and classes.
Consider applying creational patterns when:
\u2022\u2022 A system should be independent of how its objects and products are created.
\u2022\u2022 A set of related objects is designed to be used together.
\u2022\u2022 Hiding the implementations of a class library of product, revealing only their interfaces.
Creational pattern 11
\u2022\u2022 Constructing different representation of independent complex objects.
\u2022\u2022 A class want its subclass to implement the object it creates.
\u2022\u2022 The class instantiations are specified at run-time.
\u2022\u2022 There must be a single instance and client can access this instance at all times.
\u2022\u2022 Instance should be extensible without being modified.
Structure
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:
\u2022 Creator: Declares object interface. Returns object.
\u2022 ConcreateCreator: Implements object's interface.
Examples
Some examples of creational design patterns include:
\u2022 Abstract factory pattern: centralize decision of what factory
to instantiate
\u2022 Factory method pattern: centralize creation of an object of
a specific type choosing one of several implementations
\u2022 Builder pattern: separate the construction of a complex
object from its representation so that the same construction
process can create different representations
\u2022 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
\u2022 Object pool pattern: avoid expensive acquisition and release of resources by recycling objects that are no longer
in use
\u2022 Prototype pattern: used when the type of objects to create is determined by a prototypical instance, which is
cloned to produce new objects
\u2022 Singleton pattern: restrict instantiation of a class to one object
References
[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1995). Design Patterns. Massachusetts: Addison-Wesley. p. 81.
ISBN 0-201-63361-2.
[2][2] Gang Of Four
[3] Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bert, Bates (2004). Hendrickson, Mike. ed (in English) (paperback). Head First Design
Patterns (http:/ / it-ebooks. info/ book/ 252/ ). 1. O'REILLY. pp. 156. ISBN 978-0-596-00712-6. . Retrieved 2012-07-23.
[4] Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bert, Bates (2004). Hendrickson, Mike. ed (in English) (paperback). Head First Design
Patterns (http:/ / it-ebooks. info/ book/ 252/ ). 1. O'REILLY. pp. 134. ISBN 978-0-596-00712-6. . Retrieved 2012-07-23.
[5] Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bert, Bates (2004). Hendrickson, Mike. ed (in English) (paperback). Head First Design
Patterns (http:/ / it-ebooks. info/ book/ 252/ ). 1. O'REILLY. pp. 177. ISBN 978-0-596-00712-6. . Retrieved 2012-07-23.
[6] Judith, Bishop (December 2007). C# 3.0 Design Patterns (http:/ / shop. oreilly. com/ product/ 9780596527730.
do?cmp=af-orm-msdn-book-9780596527730). O'Reilly Media. pp. 336. ISBN 978-0-596-52773-0. .
[7] Design Patterns. Massachusetts: Addison Wesley. 1995. p. 84. ISBN 0-201-63361-2.
[8] Design Patterns. Massachusetts: Addision Wesley. 1995. p. 85. ISBN 0-201-63361.
Abstract factory pattern 12
Abstract factory pattern
The abstract factory pattern is a software design pattern that provides a way to encapsulate a group of individual
factories that have a common theme. In normal usage, the client software creates a concrete implementation of the
abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme. The
client does not know (or care) which concrete objects it gets from each of these internal factories, since it uses only
the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from
their general usage.
An example of this would be an abstract factory class DocumentCreator that provides interfaces to create a
number of products (e.g. createLetter() and createResume()). The system would have any number of
derived concrete versions of the DocumentCreator class like FancyDocumentCreator or
ModernDocumentCreator, each with a different implementation of createLetter() and
createResume() that would create a corresponding object like FancyLetter or ModernResume. Each of
these products is derived from a simple abstract class like Letter or Resume of which the client is aware. The
client code would get an appropriate instance of the DocumentCreator and call its factory methods. Each of the
resulting objects would be created from the same DocumentCreator implementation and would share a
common theme (they would all be fancy or modern objects). The client would need to know how to handle only the
abstract Letter or Resume class, not the specific version that it got from the