Lesson 5: More on Creational Patterns Object-Oriented Creational Paradigm Shift, Inc. Software Factory Behavioral Structural Design Patterns

Lesson Objectives Present the following Patterns: Factory Method Prototype Discuss in detail each of these creational patterns

Factory Method Pattern Creational Patterns Factory Method Pattern Topics Factory Method Description Simple Example Advantages Disadvantages Another Example Related Patterns Things to Watch out for Conclusions

Factory Method Factory method pattern is a class creational pattern that uses inheritance to vary the class of the object being created. Lets a subclass change the class of objects created by code inherited from its parent class. Provides a way to defer to user defined subclasses of the abstract class the knowledge of which abstract product subclass to create.

Factory Method: Structure AbstractClass AbstractProduct FactoryMethod() AMethod() product = FactoryMethod() ConcreteProduct ConcreteClass FactoryMethod() return new ConcreteProduct()

Factory Method: Simple Example Application Document CreateDocument() NewDocument() OpenDocument Open() Close() Save() Revert() Document* doc = CreateDocument(): docs->Add(doc); doc->Open(); MyApplication MyDocument CreateDocument() return new MyDocument()

Factory Method Pattern: Participants & Collaborations AbstractProduct (Document) defines an interface for objects that the factory method will produce ConcreteProduct (MyDocument) implements the services for the AbstractProduct interface AbstractClass (Application) declares the factory method signature , which returns an instance of AbstractProduct implements one or more methods that call the factory method ConcreteClass (MyApplication) implements the factory method that returns an instance of a ConcreteProduct Collaborations The AbstractClass relies on its subclasses to define the factory method so that it returns an instance of the appropriate ConcreteProduct.

Factory Method: Advantages Best to use when there is a default way of creating objects Easy to use, flexible - easy to define new subclasses of AbstractClass Genericity - no need to bind specific classes into frameworks; framework only deals with the interface of AbstractProduct

Factory Method: Disadvantages May result in a large set of subclasses of AbstractClass, none of which does very much. Two- class hierarchies must evolve simultaneously Defining a new subclass could result in many changes if not done correctly (i.e., ConcreteClasses should be instantiated at a single point

Factory Method: Example (2) GraphicTool Manipulate() NewGraphic() = 0 Shape Shape* s = newGraphic(): s->move(p); s->draw(); Circle Square CircleCtor SquareCtor newGraphic() newGraphic() return new Circle() return new Square()

Factory Method: Example (2) The GraphicTool class is responsible for creating and drawing specific Shapes, but it doesn’t know what kind of Shapes to create. GraphicTool defines an abstract factory operation “newGraphic” GraphicTool subclasses redefine “newGraphic” to return the appropriate Shape subclass Generic code in GraphicTool can create and use subclass- specific Shapes. The generic code that uses Shapes (Manipulate) is decoupled from the domain-specific code that creates them (newGraphic) Shape implements the abstract product; Circle and Square implement the concrete products

Related Patterns Two ways to parameterize a module with the classes of the objects it creates: Subclass the class that creates the object (Factory Method) Define an object that is responsible for knowing the class of the product objects, and make it a parameter of the module (Abstract Factory, Prototype, Builder) Abstract Factory is a collection of Factory Methods and has a class hierarchy of AbstractClasses, one for each of the subclasses of AbstractProduct Prototype has a factory object (AbstractClass) building a product by copying a prototype

Things To Watch Out For 1. The Abstract Base Class must not call this function in its constructor, as the derived class will not be available until after the base class is constructed 2. Identify factory methods with a naming convention like DoMakeProductClass() 3. This pattern ties the evolution of two hierarchies together. A new implementation may require a new kind of AbstractClass and a new kind of AbstractProduct. The changes to the AbstractClass hierarchy must be coordinated with the AbstractProduct hierarchy, where they wouldn’t be if not for the factory method

Conclusions A Factory Method is a pure virtual function in an abstract base class whose purpose in life is to create an object A Factory Method defers to the subclasses how to create the object and what ‘flavor’ of the object to create This buys flexibility

Prototype Pattern Original Clones Creational Patterns Topics Prototype Definition Music Editor Example Problems it Solves Applicability Comparison of Prototype to other Creational Patterns Benefits Remarks Original Clones

Prototype Pattern: Definition Concrete product class Each class of objects to be created must have a clone() method defined which returns a copy of itself In effect, the clone method takes the place of concrete “factory” classes in other creational design patterns The client code can specify any class as a prototype class from the class hierarchy, as long as the type used is the top- level base one

Prototype Pattern: Definition (1) Creating a “factory” class A single class is used to create all concrete product class objects The “factory” class takes a list of prototype concrete class objects at ctor time or on change methods which allows the specification of which concrete class will be registered for creation These concrete product class objects will be stored as private data in the “factory” class When client code wishes to “make” new concrete product class objects, the “factory” class make() methods are called, these methods invoke the saved prototype concrete product class objects to clone() themselves. The cloned new objects are then returned to the client code

Prototype Pattern: Structure “factory” Type “product” Type Client Prototype Operation() Clone() Prototype P = prototype->Clone() ConcretePrototype1 ConcretePrototype2 Clone() Clone() return new ConcretePrototype1(this) return new ConcretePrototype2(this)

Music Editor Example “product” Type “factory” Type Graphic Tool Draw(position) Clone() Manipulate() Staff MusicalNote GraphicTool RotateTool prototype Draw(position) Clone() Manipulate() Manipulate() WholeNote HalfNote p = prototype->Clone() while (user drags mouse) { p->Draw(new position) } insert p into drawing Draw(position) Clone() Draw(position) Clone() return new WholeNote(this) return new HalfNote(this)

Prototype Pattern: Participants & Collaborations Prototype (Graphic ) declares an interface to clone itself ConcretePrototype (Staff, WholeNote, HalfNote) implements an operation to clone itself Client (GraphicTool) creates a new object by requesting a prototype to clone itself Collaborations • Copying a prototype may require collaborating with its components. • Client requests prototype to clone itself.

More on Prototype Pattern Definition Creates new concrete product class objects by copying a prototypical instance Prototype permit clients to install and configure dynamically instances of particular classes with set attributes Client code can then request that a new class object be instantiated that is a copy of the registered concrete class object

More on Prototype Pattern (cont’d) Design Pattern Classification Prototype is a creational pattern that is concerned with the process of object creation There are two TYPEs used in this pattern. A “factory” or object creating TYPE and concrete product TYPE The “factory” TYPE is instantiated as a single class. The concrete product TYPE is instantiated as a hierarchy of class objects, but the client code only deals with base concrete product TYPE interface

More on Prototype Pattern (2) Purpose Allows the dynamic creation of new concrete class objects from a prototype or template of an existing concrete class object at run-time The new object can be a “deep” copy or “shallow” copy of the prototype class object The client code can select which concrete class object will be registered with the “factory” class at run-time. This “factory” class will then create copies of the registered concrete product class for client code specify specific class at run-time also change which kind of concrete product classes are registered at run- time

More on Prototype Pattern (2) Usage This pattern can be used when one public base TYPE will be used by client code for creating class objects. This single TYPE will also have a single class implementation. This public TYPE can be classified as a “factory” TYPE with methods to create concrete product class objects for client code. These created concrete class objects will be of a single TYPE but may be implemented as a hierarchy of classes. Behavior The new concrete class objects created will be a clone of the prototype class object but will allow attribute modifications on the copied class objects that can be specified as make() method parameters. What the prototype looks like can be changed dynamically at run-time by the client code. This done by specifying different concrete class objects on the constructor or change() methods of the “factory” creating class.

Applicability This pattern is used when a system should be independent of how its products are created, composed, and represented Dynamic object specification Allows run-time specification of which class/subclass should be created by client code No class hierarchies of “factory” classes Uses a single created “factory” class to create all classes and subclasses of concrete product class objects Dynamic attribute specification for concrete class objects The newly created concrete product objects will have a copy of the attributes or state of the registered prototype object Client code can also specify attribute changes at creation time by using make method parameters: “copy with changes capability” Automatic extension of class inheritance tree for product classes Automatically accommodates all in subclasses of concrete classes, since the creation logic is always attached to the concrete product class in clone() methods and not in a separate concrete “factory” class

Prototype versus Factory Method Factory uses a hierarchy of “factory” creating classes that parallels the concrete product classes being created. By using the desired “factory” concrete subclass, the client code can create different kinds of objects Prototype uses only one creating “factory” class, and allows different object creation to happen dynamically

Prototype versus Abstract Factory Method (PURE) Allows the specification of one abstract factory class that the client code always uses Still uses a hierarchy of factory-creating classes that parallels the objects classes being created But allows parameters to be specified at run-time to determine which concrete factory will be used to create system objects Prototype The advantage of prototype over this method is that only one “factory” class is needed

Prototype versus Builder Uses a separate class to create the new concrete product objects A builder class is created for each product class that encapsulates the complexity of creating the object Prototype The advantages of prototype over this method are: 1. Prototype needs only one “factory” class to create all subclasses of product objects 2. The creation logic is attached directly to each product class

Benefits Hides concrete product classes from the client code This reduces the names known to the client and allows the client to work with application-specific classes without being modified Allows adding new concrete product classes By registering the new classes & subclasses as prototypical instances at run-time Allows the dynamic changing of concrete product classes at run-time Client code can change which classes are created on the fly May reduce the number of product classes needed If attributes of a class can be used to differentiate objects, prototype can eliminate the need for additional classes, since the same class can be prototyped by using multiple instances of the class registered with different attributes Eliminates the need for a hierarchy of concrete creating “factory” classes

Prototype Pattern: Type Diagram Prototype manager PrototypeManager make() addPrototype() rmvPrototype() Prototype Prototype clone()

Prototype - Simple Example Car factory object as the prototype manager When the instance of carFactory is created: A prototype (instance) of each model is created (ford, buick, chevy) The attributes of each model are initialized (tires, engine, color, trans, etc.) Client can: Request copies of the prototypes Add a prototype to the prototype manager to be copied later Remove a prototype from the prototype manager

Prototype: Deep Copy versus Shallow Copy Copying composite objects Base Object Component Object Deep copy -- returns a full copy of the base objects & all of its components Original Copy

Prototype: Deep Copy versus Shallow Copy (continue) Shallow copy -- returns a copy of the base object & pointers to the components Original Component Object Copy Needs to be very clear in the specification

Discussion Questions Mark (T) for true or (F) for false ( ) 1. Factory Method is best to use when there is a default way of creating objects. ( ) 2. In Factory Method implementation, there are two class hierarchies MUST evolve simultaneously. ( ) 3. The Abstract Factory and Prototype patterns work best when a system needs to be customized. ( ) 4. Prototype pattern takes more work to apply to an existing system. ( ) 5. Abstract Factory, Builder, and Prototype Patterns involve creating a new object whose responsibility is to create the product objects . ( ) 6. Deep copy returns a copy of the base object and the pointers to the components. ( ) 7. Shallow copy returns a full copy of the base object and all of its components.