Tech Talk Go4 Factory Patterns Presented By: Matt Wilson

Introduction 2  This presentation originated out of casual talk between former WMS “C++ Book Club” (defunct program) developers who wanted to continue to get together on occasion to discuss technical topics.  Sources used here included the Gang of 4 Design Patterns Book, Head First Design Patterns book, and many online articles and discussion boards on the topic.

What-is/Why-use a Factory pattern? 3  Encapsulates creation in one place.  Decouples clients from having to know about Subtypes.  When you are making a library and want to provide a creational interface for your Clients.  When you want to have the ability for Random types to be created at runtime. Example: A game that generates random types of enemies from an enemy “factory”.

No Factory Example 4 Hot dog store! White board it – No Factory. Any OO design problems seen here? (psudocode) Hotdog HotDogStore::orderHotDog(type) { Hotdog * dog = null; If (type == corndog) { dog = new CornDog(); } else if (type == PolishDog) { dog = new PolishDog(); } return dog; }

No Factory - Problems 5 Violates two of the five fundamental Principals of SOLID OO Design:SOLID 1) Violates Open Closed Principle Open for extension, but closed for modification Or as I like to put it: Writing new code shouldn’t require a change to existing code New HotDog types would require Client Code to change to support them. Violation makes code fragile and breaks existing code. 2) Violates Dependency Inversion Principle: Classes shouldn’t have references to Concrete Classes Violation creates dependency problems, longer compile times, and prohibits Unit Testing/dependency injection.

Factory attempt 1 6 White board it… what do you think? Factory encapsulates the logic of creating types. Client no longer depends on Concrete Products. Hotdog HotDogStore::orderHotDog(type) { Hotdog * dog = null; dog = HotDogSimpleFactory::CreateDog(type); return dog; }

Simple Factory 7 Better, now the Client doesn’t depend upon Concrete products, and Creation is encapsulated, but this is not yet Factory Method Commonly used, but not a Design Pattern. Called “Simple Factory” or “Static Factory” if Static.

Factory Method 8  Why Factory Method?  Simple Factory may be the correct choice if you have a simple program.  The intent of Factory Method is "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.“  Why would you want to do this? Because it creates an extensible framework for adding future factories and products.  Use when you are going to have one or more families of classes

Factory Method UML 9  Creator may be  pure interface,  abstract or even  concrete  Enables you to extend  your factory with  new products  and creators

Factory Method – Multiple Concrete Types 10 Client can now chose one or more factories to instantiate to produce different products.

Factory Method - Example 11  Extend HotDogStore (Whiteboard) and Show how you can have multiple concrete creators and products.  This extensible Framework can support many different clients that may be using your classes in different ways. Example: Hotdog ChicagoHotDogStore::orderHotDog(type) { Hotdog * dog = null; HotDogFactory chicagoDogs = new ChicagoHotDogFactory (); dog = chicagoDogs.createHotDog(type); return dog; } or Hotdog NewYorkHotDogStore::orderHotDog(type) { Hotdog * dog = null; HotDogFactory newYorkDogs = new NewYorkHotDogFactory (); dog = newYorkDogs.createHotDog(type); return dog; }

Factory Method - Example 12  Clearly the Factory pattern is a Framework for extending the software with new types in the future.  Enables you to effectively extend your system with new Products and Factories, without effecting Client Code.  Note: Passing in “Type” is optional, and often not used as part of Factory Method.

Factory Method Questions ? 13

Abstract Factory 14  The intent of Abstract Factory is "Provide an interface for creating families of related or dependent objects without specifying their concrete classes."  Or put another way: "The intent of an Abstract Factory is to provide an interface for a creating a set of related objects.“  Biggest difference between Abstract Factory and Factory Method, Abstract Factory defines an interface with multiple create methods, whereas Factory Method has a single method.  Factory method API: “CreateHotDog”  Abstract Factory API: “CreateLettuce, CreateBun, CreatePickle, etc.”

Abstract Factory 15 *Compare to Factory Method. Very similar, but with multiple Create methods.

Abstract Factory 16  Abstract Factory provides an API to create not only 1, but n number of related objects.  In once sense,  Factory Method is an Abstract Factory with only one create method, or...  Abstract Factory is a Factory Method with multiple create methods.  See diagram below for a good Abstract Factory example for abstracting away the type of Database a Client is communicating with.

Abstract Factory - Example 17

Abstract Factory 18  So why not just call Abstract Factory, “Factory Method N- number”? Why have two patterns that are so similar?  Because, the Go4 book defines Abstract Factory as simply an interface for creating products. It's up to Concrete subclass’ implementation to create them. The most common way to do this is to define a factory method for each product as shown above.  Although an Abstract Factory “most commonly” uses Factory Methods they are not limited to them.  Alternatives include (but are not limited to) Abstract Factories that use:  BuilderPattern (builds objects in a series of steps)  PrototypePattern (builds objects by copying and customizing a prototype of the object)

Questions ? 19