Low Budget Productions, LLC Presents “The Factory Method Pattern”

Co-Executive Producers Trisha Rogers Gamma, Helm, Johnson and Vlissides Martin Fowler Wikipedia A host of internet writers Creative Consultant Mark Shacklette

Act I: Scene 1: Design for Change Open for extension but closed for modification Design system to evolve while maximizing code reuse and eliminating changes to existing classes and client classes Factory Method Pattern: Take the code that is likely to change over time and put it in its own class Create objects without specifying the exact class of the object that will be created Commit to the interface not the implementation Factory Method Pattern: defers instantiation to subclasses

Act I: Scene 2: Design pattern space Purpose: A creational pattern, concerned with the process of object creation Scope: Class scope Factory Method Pattern applies primarily to classes and their subclasses These relationships are established through inheritance and so are static - fixed at compile time. Factory Method Pattern deals with the dilemma of not knowing what the client will want until run-time.

Act I: Scene 3: Factory Method Purpose Problems: What if it is the nature of the application to have classes that change on a regular basis (new products, e.g.) and code re-writing will have to be done frequently? What if the classes are abstract and they do not know how the subclasses will be implemented? Solution: Factory Method Pattern can defer instantiation to subclasses, encapsulating the knowledge of which subclass to create and move this knowledge to a separate class. This pattern helps to model an interface for creating an object which at creation time can let its subclasses decide which class to instantiate. It is called a Factory Pattern since it is responsible for "Manufacturing" an Object. It helps instantiate the appropriate Subclass by creating the right Object from a group of related classes. The Factory Pattern promotes loose coupling by eliminating the need to bind application-specific classes into the code. Continue with slide 11

Act I: Scene 3: Factory Method Purpose Variation on the theme: Parameterized factory methods Problem: What if there is ambiguity in the meaning of the constructor parameters? Only one constructor is allowed per class, and while overloading will solve the problem of passing different types of parameters, it will not solve problem of the same type with different meanings. Solution: Create a factory class that will privatize the constructor and pull all the logic into one class. Provide different static methods to return the appropriate object depending on the meaning. Example to follow. Problem: You want a simple concrete creator class to handle object creation depending on a passed parameter? Solution: Create a factory class that will privatize the constructor and pull all the logic into one class. Write a switch statement to handle various parameters. If there is an addition of a sub-class, fix code in the factory class only. The interface does not change. Example to follow.

Act I: Scene 4: Where to use it Three basic situations Frameworks High level software written for an industry Abstract classes used to define and maintain relationships between objects A company in the industry will purchase the framework and implement the subclasses to its own specifications So if there aren’t many/any subclasses in the framework, how does the framework developer create objects? Encapsulates the knowledge of which subclass to create and moves this knowledge out of the framework Parallel hierarchies Application class cannot anticipate the subclass to be instantiated at run-time; it knows when, not what kind. “Little Factories” with logic in one place

Act I: Scene 5: UML per GoF

Act II: Scene 1: Old Approach

Act II: Scene 2: Factory Method

Act II: Scene 2: Factory Method Scenario: A bank has multiple types of accounts. These are subclasses of the class Account. There is a saving account class and a checking account class. The client uses a factory method class as an interface. When a new type of account is added – an IRA account – no changes need to be made to the abstract account class, the savings account class or the checking account class. More importantly, no changes need to be made to the client class. Only changes in the factory class need to be made to add the new product – IRA account. See the example in Eclipse.

Act II: Scene 3: Disambiguation Example How to use a factory method pattern to solve problem of multiple meanings for parameters: Make the constructor private Add one or more factory methods that are static and accessible from the public class. Example is from Wikipedia. class Complex { private Complex(double a, double b) { //... } public static Complex fromCartesian(double real, double imag) { return new Complex(real, imag); } public static Complex fromPolar(double modulus, double angle) { return new Complex(modulus * cos(angle), modulus * sin(angle)); Complex c = Complex.fromPolar(1, pi); // Same as fromCartesian(-1, 0)

Act III: Scene 1: Limitations The first limitation is that refactoring an existing class to use factories breaks existing clients. For example, if class Complex was a standard class, it might have numerous clients with code like: Complex c = new Complex(-1, 0); Once we realize that two different factories are needed, we change the class (to the code shown earlier). But since the constructor is now private, the existing client code no longer compiles. The second limitation is that, since the pattern relies on using a private constructor, the class cannot be extended. Any subclass must invoke the inherited constructor, but this cannot be done if that constructor is private. The third limitation is that, if we do extend the class (e.g., by making the constructor protected -- this is risky but possible), the subclass must provide its own re-implementation of all factory methods with exactly the same signatures. For example, if class StrangeComplex extends Complex, then unless StrangeComplex provides its own version of all factory methods, the call StrangeComplex.fromPolar(1, pi) will yield an instance of Complex (the superclass) rather than the expected instance of the subclass. Continue with slide 11

Coda: Never, ever follow student presenter Will Rodgers (the state pattern with the Pepsi machine guy) in any presentations. Ever.