Creational Patterns Making Objects The Smart Way Brent Ramerth Abstract Factory, Builder

What are creational patterns? Design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation Make a system independent of the way in which objects are created, composed and represented Recurring themes: –Encapsulate knowledge about which concrete classes the system uses (so we can change them easily later) –Hide how instances of these classes are created and put together (so we can change it easily later)

Benefits of creational patterns Creational patterns let you program to an interface defined by an abstract class That lets you configure a system with “product” objects that vary widely in structure and functionality Example: GUI systems –InterViews GUI class library –Multiple look-and-feels –Abstract Factories for different screen components

Benefits of creational patterns Generic instantiation – Objects are instantiated without having to identify a specific class type in client code (Abstract Factory, Factory) Simplicity – Make instantiation easier: callers do not have to write long complex code to instantiate and set up an object (Builder, Prototype pattern) Creation constraints – Creational patterns can put bounds on who can create objects, how they are created, and when they are created

Abstract Factory: An Example PIM system Manage addresses and phone numbers –You hard-coded it for US data –At some point, you wanted to extend it to incorporate any address / phone number –So you subclassed DutchAddress, JapanesePhoneNumber, etc. –But now, how do you create them?

Abstract Factory: Overview Intent –Provide an interface for creating families of related or dependent objects without specifying their concrete classes Analogous to a pasta maker Your code is the pasta maker Different disks create different pasta shapes: these are the factories All disks have certain properties in common so that they will work with the pasta maker All pastas have certain characteristics in common that are inherited from the generic “Pasta” object

Abstract Factory: Participants AbstractFactory Declares an interface for operations that create abstract products ConcreteFactory Implements the operations to create concrete product objects: usually instantiated as a Singleton AbstractProduct Declares an interface for a type of product object; Concrete Factories produce the concrete products ConcreteProduct Defines a product object to be created by the corresponding concrete factory

Abstract Factory: Applicability Use Abstract Factory when: –A system should be independent of how its products are created, composed, and represented –A system should be configured with one of multiple families of products –You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations

Abstract Factory: Consequences Good: –Isolates concrete classes All manipulation on client-side done through abstract interfaces –Makes exchanging product families easy Just change the ConcreteFactory –Enforces consistency among products Bad –Supporting new kinds of products is difficult –Have to reprogram Abstract Factory and all subclasses –But it’s not so bad in dynamically typed languages

Abstract Factory: Implementation Usually should be a Singleton Define a Factory Method (GoF) in AbstractFactory – ConcreteFactory then specifies its products by overriding the factory for each public class USAddressFactory implements AddressFactory{ public Address createAddress(){ return new USAddress(); } public PhoneNumber createPhoneNumber(){ return new USPhoneNumber(); } Maybe use Prototype pattern in dynamically typed languages (e.g. Smalltalk) to simplify creation

Builder: Overview Intent –Separate the construction of a complex object from its representation so that the same construction process can create different representations Think of a car factory –Boss tells workers (or robots) to build each part of a car –Workers build each part and add them to the car being constructed

Builder: Participants Builder Specifies an abstract interface for creating parts of a Product object ConcreteBuilder Constructs and assembles parts of the product by implementing the Builder interface Director Constructs an object using the Builder interface Product Represents the complex object under construction Includes classes that define the constituent parts Gives interfaces for assem- bling the parts

Builder: Collaborations Client creates Director object and configures it with a Builder Director notifies Builder to build each part of the product Builder handles requests from Director and adds parts to the product Client retrieves product from the Builder

Builder: Applicability Use Builder when: –The algorithm for creating a complex object should be independent of the parts that make up the object and how they’re assembled –The construction process must allow different representations for the object being constructed –The building process can be broken down into discrete steps (difference between Builder and Abstract Factory)

Builder: Consequences Lets you vary a product’s internal representation by using different Builders Isolates code for construction and representation Gives finer-grain control over the construction process

Builder: Implementation Issues to consider: –Assembly and construction interface: generality –Is an abstract class for all Products necessary? Usually products don’t have a common interface –Usually there’s an abstract Builder class that defines an operation for each component that a director may ask it to create. These operations do nothing by default (empty, non- virtual methods in C++) The ConcreteBuilder overrides operations selectively

Conclusions Creational design patterns are beneficial in that they allow your software to tightly control the way in which it constructs objects Separate users of the code from the messy details of creating and building objects

Conclusions Abstract Factory: –Lets you choose what family of products to create at runtime –Isolates the implementation from clients, since clients only use the interfaces –Makes exchanging product families simple

Conclusions Builder: –Lets you vary how a product gets assembled. –Can define a new kind of builder for a product to assemble it in a different way –Client doesn’t need to know anything about the construction process, nor the parts that make up a product.

Questions?