The Factory Patterns

1. The Factory Patterns SE-2811 Dr. Mark L. Hornick

2. Direct instantiation is a disadvantage The issue/problem/context: • A client needs to create one of several (or many) types of (similar) objects • Creation of objects may need to be happen within various differing locations within the app (distributed creation) • Client doesn’t want to know specifically what kind of object to create • Client may need to incorporate intelligence such as “thread awareness” in order to create the objects on the correct thread • Object creation may need to be a multi-step procedure • Hard to maintain – may require a lot of different “new’s” • And generally, we want to program to interfaces or abstract classes

3. Scenario: Client directly creates class instances SE-2811 Dr. Mark L. Hornick

4. Factory Design Pattern Solution • Define an interface for object creation methods in an abstract Factory class that can be used by the Client whenever concrete objects (aka Products) need to be created • The interface consists of methods known as Factory Methods • Let some concrete subclass decide specifics • By providing an implementation of the Factory Methods • This delegates the decision of what/how to create to the concrete subclasses

5. Factory Pattern • The interface consists of Factory Methods • Creation is not done via constructor methods because constructor methods cannot be overridden SE-2811 Dr. Mark L. Hornick

6. Factory pattern • The concrete factory (USMoneyMint) implements a single Factory Method (createCurrencyMaker), which instantiates concrete Products (DollarBillMaker or DollarCoinMaker) • But the client still has to create the Factory (USMoneyMint) that creates the CurrencyMakers • There are two Products being built here by the USMoneyMintFactory – DollarCoinMakerand DollarBillMaker SE-2811 Dr. Mark L. Hornick

7. Factory Summary • Defines an interface (Factory Methods), implemented in a concrete Factory, for creating Product objects • The interface specifies a special method (Factory Method) that is invoked by clients • Creation is not done via constructor methods because constructor methods cannot be overridden in classes that extend the abstract class SE-2811 Dr. Mark L. Hornick

8. Abstract Factory classes • The next level of extension of the Factory concept • The products created by are sufficiently different to warrant separate Factories • Whose “factory methods” are similar SE-2811 Dr. Mark L. Hornick

9. Abstract Factory • The abstract factory (MoneyMint) defines the Factory Method implemented by the concrete factories, which is used by the client to create CurrencyMakers • But the client still has to create the concrete Factories (USMoneyMint), but can refer to them abstractly (via MoneyMint references) The products created by are sufficiently different to warrant separate Factories (USMoneyMint and CanadianMoneyMint), each of which “knows” which products to make

10. Abstract Factory Abstract classes • MoneyMint (abstract factory) • CurrencyMaker (abstract product) USMoneyMint (concrete factory) creates instances of CurrencyMakers (concrete Product) • But only concrete USMoneyMint class knows the concrete type of CurrencyMaker (DollarBillMaker, DollarCoinMaker) to create • The framework (client) used by the client app only references abstract CurrencyMaker classes • The client application should only access the framework’s abstract classes (whenever possible)

11. Abstract Factory Pattern(generic) SE-2811 Dr. Mark L. Hornick

12. Extending the abstraction further The Concrete Factories (USMoneyMint and CanadianMoneyMint) still have to be created by the client app • So we still have the client app dealing with non-abstract classes and using “new” • But we can even abstract this away by using static methods in the Abstract Factory class…

13. Abstract Factory method • Here, the Abstract Factory (MoneyMint) exposes a static factory method (createMint) that can be called to create the concrete factories (the US and Canadian Mints). • In addition, the client is forced to use the createMint method, since the concrete classes have protected constructors. The client app only has to reference the abstract classes in this configuration.

14. Abstract Factory Implementation • Abstract Factory is a true abstraction • The client only deals with the Abstract Factory class • The client never creates concrete Factories • Subclasses of the abstract factory class “decide” what concrete object to create, based on the subclasses actual implementation of the factory method • This allows the abstract (Factory) class defer instantiation (of the Product) to subclasses at runtime • Parameterized abstract factory methods • Multiple product variants • Choice selected by parameter

15. Abstract Factory Advantages • Provides “hooks” for additional subclasses • Permits subclass to modify product creation by overriding the abstract factory method • But base class can provide a default if needed!

16. Abstract Factory - Disadvantages • Supporting new products is not easy • The factory interface has to be extended for each new product • Changing the Abstract Factory class interface changes all its subclasses

17. Overriding design principles motivating the Factory patterns • No variable should hold a reference to a concrete class • No class should derive from a concrete class • No method should override an implemented method of any of its base classes • These are guidelines that we strive for, but cannot always follow 100% SE-2811 Dr. Mark L. Hornick