creational patterns
DESCRIPTION
PatternsTRANSCRIPT
-
*Creational Design Patterns:Elements of Reusable Object Oriented SoftwareSuganthy. A
Design Patterns
-
Design Patterns*Design Pattern Creational PatternsProtoptypeBuilderAbstract FactoryFactory MethodsingletonBibliography
Design Patterns
-
Design Patterns*Creational Pattern
SingletonEnsure a class only has one instanceProvide a global point of access to it
Abstract Factory:Provide an interface for creating families of related or dependent objects without specifying their concrete classes
Design Patterns
-
Design Patterns*Creational PatternFactory Method:Define an interface for creating an object but let subclasses decide which class to instantiateLets a class defer instantiation to subclasses
Prototype Specify the kinds of objects to create using a prototypical instanceCreate new objects by copying this prototype
Design Patterns
-
Design Patterns*Creational PatternBuilder:Separate the construction of a complex object from its representation so that the same construction process can create different representations
Design Patterns
-
Design Patterns*Singleton PatternIntentEnsure a class only has one instance, and provide a global point of access to it.Motivationwe need to have exactly only one instance for a class (ex. Printer spooler)Make the class itself responsible for keeping track of its sole instance The class provide a way to access the instanceApplicabilityThere must be only one instance of a class accessible from a well-known point
Design Patterns
-
Design Patterns*Singleton PatternStructureSingletonStatic Instance()SingletonOperation()GetSingletonData()Static uniqueInstanceSingletonDataReturn uniqueInstance
Design Patterns
-
Design Patterns*Singleton PatternParticipantsSingleton classCollaborationsAccess only through Singletons instance operationConsequencesControlled access to sole instancePermits refinement of operation and representationMore flexible than class operationsReduced name space
Design Patterns
-
Design Patterns*Example of Singleton useWe had to have only one instance for class Director. We simply solve our problem using Singleton Pattern
DirectorStatic Instance()Given(n_ticket:int):voidError():voidStatic UniqueInstance
Design Patterns
-
Design Patterns*Singleton class Singleton {
}// Only one instance can ever be created.
Design Patterns
-
*Singleton Singleton* Singleton::_instance=0;Singleton* Singleton:: Instance(){
if (_instance ==0) {_instance=new Singleton;}Return _instance;
}// Clients access the singleton // exclusively via the Instance member // function.
-
Design Patterns*Singleton Related PatternAbstract FactoryBuilderPrototype
Design Patterns
-
Design Patterns*Abstract FactoryIntentProvide an interface for creating families of related or dependent objects without specifying their concrete classes
Also known asKit
Design Patterns
-
Design Patterns*Abstract FactoryMotivation (Problem)Consider a user interface toolkit to support multiple look-and-feel standards. For portability an application must not hard code its widgets for one look and feel.How to design the application so that incorporating new look and feel requirements will be easy?
Design Patterns
-
Design Patterns*Abstract FactorySolution
2.This class declares an interface to create different kinds of widgets.1.Define an abstract WidgetFactory class.3.There is one abstract class for each kind of widget and concrete subclasses implement widgets for different standards.4.WidgetFactory offers an operation to return a new widget object for each abstract widget class. Clients call these operations to obtain instances of widgets without being aware of the concrete classes they use.
Design Patterns
-
Abstract FactoryDesign Patterns*
Design Patterns
-
Abstract FactoryDesign Patterns*ConcreteFactory: Implements the operations to create concrete product objects.AbstractProduct: Declares an interface for a type of product object.ConcreteProduct: Defines a product object to be created by the corresponding factory. AbstractFactory: Declares the interface for operations to create abstract product objectsClient: Uses only the interface declared by the abstractFactory and AbstractProduct classes.Participants and Communication
Design Patterns
-
Design Patterns*Factory MethodIntentDefine an interface for creating an object, but let subclasses decide which class to instantiate.Factory method lets a class defer instantiation to subclasses.Also Known asVirtual constructor
Design Patterns
-
Factory MethodDesign Patterns*1.Frameworks use abstract classes to define and maintain relationships between objects2.Consider a framework for applications that present multiple documents to the user. A drawing application is an example.3.This framework defines two abstract classes: application and document. These ought to be sub classed by clients for application specific implementation.4.The application class will create and manage documents when required, e.g. when a New command is selected from the menu.Motivation (The problem)
Design Patterns
-
Factory MethodDesign Patterns*5.Document sub class is application specific. Hence the Application class does not know what kind of document to create!6.Problem: The framework must instantiate classes but it only knows about the abstract classes, which it cannot initiate!
Design Patterns
-
Factory MethodDesign Patterns*2.Application subclasses redefine an abstract CreateDoc() method to return the appropriate Document subclass.1.The Factory Method pattern encapsulates the knowledge of which Document subclass to create and moves this knowledge out of the framework.3.When an Application is instantiated, it can instantiate application specific Documents without knowing their class.The Solution
Design Patterns
-
Factory MethodDesign Patterns*
Design Patterns
-
Factory MethodDesign Patterns*Structure of Factory Method
Design Patterns
-
Factory MethodDesign Patterns*ConcreteProduct (MyDocument): Implements the Product interface.Creator (Application): Declares factory method which returns an object of type Product. Also, may define the factory method to create a Product object.ConcreteCreator (MyApplication): Overrides the factory method to return an instance of a ConcreteProduct.Product (Document): Defines the interface of objects the factory method creates. Participants and Communications
Design Patterns
-
BuilderIntentThe Builder Pattern separates the construction of a complex object from its representation so that the same construction process can create different representations.
Design Patterns*
Design Patterns
-
BuilderStructureDesign Patterns*
Design Patterns
-
BuilderParticipantsBuilder - specifies an abstract interface for creating parts of a Product object. ConcreteBuilder - constructs and assembles parts of the product by implementing the Builder interface. Also, it defines and keeps track of the representation it creates and provides an interface for retrieving the product . Director - constructs an object using the Builder interface. Product - represents the complex object under construction.
Design Patterns*
Design Patterns
-
BuilderCollaborations
The client creates the Director object and configures it with the desired Builder object. Director notifies the builder whenever a part of the product should be built. Builder handles requests from the director and adds parts to the product. The client retrieves the product from the builder.
Design Patterns*
Design Patterns
-
Builder
Design Patterns*
Design Patterns
-
BuilderUse he Builder pattern when:
The algorithm for creating a complex object should be independent of the parts that make up the object and how they are assembled. The construction process must allow different representations for the object that is constructed.
Design Patterns*
Design Patterns
-
BuilderConsequencesA Builder lets you vary the internal representation of the product it builds. It also hides the details of how the product is assembled.Each specific builder is independent of the others and of the rest of the program. This improves modularity and makes the addition of other builders relatively simple.Because each builder constructs the final product step-by-step, depending on the data, you have more control over each final product that a Builder constructs.
Design Patterns*
Design Patterns
-
BuilderA Builder pattern is somewhat like an Abstract Factory pattern in that both return classes made up of a number of methods and objects. The main difference is that while the Abstract Factory returns a family of related classes, the Builder constructs a complex object step by step depending on the data presented to it.
Related PatternsAbstract FactoryComposite
Design Patterns*
Design Patterns
-
PrototypeIntentSpecify the kinds of objects to create using a prototypical instance, and create new objects by copying (cloning) this prototype.
Design Patterns*
Design Patterns
-
PrototypeStructureDesign Patterns*
Design Patterns
-
PrototypeParticipantsPrototype(Graphic)Declares an interface for cloning itselfConcretePrototype (Staff, wholeNote, HalfNote)Implements an operation for cloning itself.Client(GraphicalTool)Creates a new object by asking a prototype to clone itself
Design Patterns*
Design Patterns
-
PrototypeApplicabilityThe prototype pattern is used when a system should be independent of how its products are created, composed, and represented; [i.e., concrete product classes are hidden from client - similar to Builder or Abstract Factory]
Design Patterns*
Design Patterns
-
Prototypewhen the classes to instantiate are specified at run-time; for example, through dynamic loading; ORto avoid building a class hierarchy of factories that parallels the class hierarchy of products; ORwhen instances of a class can have one of only a few different combinations of state
Design Patterns*
Design Patterns
-
PrototypeConsequencesIsolating concrete product classes from the client. Dynamically adding and removing product classes at run-time. Specifying new predefined objects by varying values/varying structure.Reducing the need for sub-classing. Configuring an application with classes dynamically.Main possible liability: Clone() needed.
Design Patterns*
Design Patterns
-
Design Patterns*Bibliography
Erich Gamma, Richard Helm,Ralph Johnson,John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. ADDISON-WESLEY 1995
Design Patterns