Creational Patterns

Abstract Factory, Builder

Making Objects
The 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
• 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?