Creational Patterns

Creational Patterns Abstract Factory, Builder Making ObjectsThe Smart Way Brent Ramerth

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 • AbstractFactoryDeclares an interface for operations that create abstract products • ConcreteFactory Implements the operations to create concrete product objects: usuallyinstantiated 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 (orrobots) to build eachpart of a car • Workers build each part and add them tothe car being constructed

Builder: Participants • BuilderSpecifies 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 constructionIncludes classes that define the constituent partsGives 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?

Creational Patterns