1. Ms Munawar Khatoon IV Year I Sem Computer Science Engineering
Creational Patterns
Abstract Factory, Builder
Ms Munawar Khatoon
IV Year I Sem
Computer Science Engineering
Brent Ramerth

2. 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)

3. 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

4. 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

8. 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?

9. Abstract Factory: Overview
Intent
Provide an interface for creating families of related or dependent objects without specifying their concrete classes
also known as
--kit
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

10. 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

11. 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

12. 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

13. 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

14. Builder: Overview Intent Think of a car factory
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

15. 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: The abstract class of all workers
Concrete Builder: A specific worker
Director: The boss Product: The car

16. 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

18. 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)

19. 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

20. 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

21. 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

22. 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

23. 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.

24. Questions?