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

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

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

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

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

Factory pattern SE-2811 Dr. Mark L. Hornick 6 There are two Products being built here by the USMoneyMint Factory – DollarCoinMaker and DollarBillMaker 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

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 7

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 8

Abstract Factory 9 The products created by are sufficiently different to warrant separate Factories (USMoneyMint and CanadianMoneyMint), each of which “knows” which products to make 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)

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)

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

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…

Abstract Factory method 13 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.

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

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!

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

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 17