The Factory Method Design Pattern Motivation: Class / Type separation – Abstract class serves as type definition and concrete class provides implementation – In a language which distinguishes between class and type, there must be a mechanism for creation of an object which would reveal its type, but not its class. – Unfortunately, in Java, the best known language in which such a separation exists, there is no such mechanism. Abstract Methods deal exactly with this problem. The Abstract Factory Generalizes. Pattern Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate. Lets a class defer instantiation to subclasses

Factory Method Motivation

Factory Method pattern Motivation Document* doc = CreateDocument(); docs.Add(doc); doc->Open(); Application CreateDocument() NewDocument() OpenDocument() Document Open() Save() Close() Revert() docs MyDocument MyApplication CreateDocument() creates return new MyDocument

Factory Method Structure Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Factory Method Consequences

Factory Method pattern Motivation (cont.) Application class is responsible for creation (and management) of Documents Problem: – Application class knows: WHEN a new document should be created – Application class doesn’t know: WHAT KIND of document to create Solution: – Application subclasses redefine abstract CreateDocument() method to return an appropriate Document subclass instance

Connecting parallel hierarchies LineFigure CreateManipulator() TextFigure CreateManipulator() LineManipulator DownClick() Drag() TextManipulator DownClick() Drag() Manipulator DownClick() Drag() Client Figure CreateManipulator() creates Localizes knowledge of which classes belongs together

Factory Method pattern Structure Product ConcreteProduct Creator FactoryMethod() AnOperation() ConcreteCreator FactoryMethod() creates... product= FactoryMethod()... return new ConcreteProduct

Factory Method pattern Applicability Use the Factory Method pattern when – a class can’t anticipate the class of objects it must create – a class wants its subclasses to specify the object it creates – classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate

Factory Method pattern Participants Product (Document) – defines the interface of objects the factory method creates ConcreteProduct (MyDocument) – implements the Product interface Creator (Application) – declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object. – may call the factory method to create a Product object ConcreteCreator (MyApplication) – overrides the factory method to return an instance of a ConcreteProduct

Factory Method - Consequences Advantage – eliminates the need to bind application specific classes into your code; your code deals with Product interface implemented by ConcreteProduct subclasses Potential disadvantage – clients might have to subclass the Creator class just to create a particular (I.e., 1) ConcreteProduct object Provides hooks for subclasses – Factory Method gives subclasses a hook for providing an extended version of an object Connects parallel class hierarchies – see next slide for example

Connecting parallel hierarchies LineFigure CreateManipulator() TextFigure CreateManipulator() LineManipulator DownClick() Drag() TextManipulator DownClick() Drag() Manipulator DownClick() Drag() Client Figure CreateManipulator() creates Localizes knowledge of which classes belongs together

Factory Method - Implementation Two major varieties – Creator declares ABSTRACT factory method, ConcreteCreator implements it – Creator defines a default implementation for factory method Parameterized factory methods – lets the factory method to create multiple kinds of objects – factory methods takes a parameter: a kind of object to create – all products have to share a Product interface

Parameterized factory methods class Creator { public: virtual Product* Create(ProductId); }; Product* Creator::Create(ProductId id) { if (id == MINE) return new MyProduct; if (id == YOURS) return new YourProduct; return 0; } Product* MyCreator::Create(ProductId id) { if (id == THEIRS) return new TheirProduct; return Creator::Create(id); }

Language-specific variants Smalltalk Class Creator … factoryMethod ^self productClass new … Class ConcreteCreator … productClass ^ConcreteProduct

Language-specific variants C++ “Lazy evaluation” class Creator { public: Product* GetProduct(); protected: virtual Product* CreateProduct(); private: Product* _product; }; Product* Creator::GetProduct() { if (_product == 0) _product = CreateProduct(); return _product; }

Using templates to avoid subclassing class Creator { public: virtual Product* CreateProduct() = 0; }; template class StandartCreator : public Creator { public: virtual Product* CreateProduct(); }; template Product* StandartCreatot ::CreateProduct(){ return new TheProduct; }