1. Creational Design Patterns
Yaodong Bi
September 22, 2005

2. Creational design patterns
Factory
Abstract Factory
Prototype
Singleton
Builder

3. Factory Problem Design Purpose Design Pattern Summary
The client needs to create an object of a subclass, but it does not know the subclass until runtime.
Design Purpose
Create individual objects in situations where the constructor alone is inadequate.
Design Pattern Summary
Use methods to return required objects

4. Factory – an example Client stack MyStack void useStack(Stack s) {
while (condition) {
stackn = new Stack(); //????? }
Stack = new MyStack();
useStack(s); //?????
stack
+push()
+pop()
MyStack
+push()
+pop()

5. Factory - structure Client Product Creator Concrete Creator Concrete
void useProduct(Creator c) {
Product p = c.factoryMethod();
// use p } ….
Creator c = new ConcreteCreator();
useProduct(c);
Client
+useProduct()
Product
Creator
+factoryMethod()
Product factorMethod() {
Return new
ConcreteProduct(); }
Concrete
Creator
+factoryMethod()
Concrete
Product

6. Factory - participants
Product
defines the interface of objects the factory method creates.
ConcreteProduct
implements the Product interface.
Creator
declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object.
Creator and Product could be the same class
ConcreteCreator
overrides the factory method to return an instance of a ConcreteProduct.
Client
It depends only on Product and Creator.
Collaborations
Creator relies on its subclasses to define the factory method so that it returns an instance of the appropriate ConcreteProduct.

7. Factory – sequence diagram
Concrete
Creator
Client
Creator
Product
Concrete
Product
factoryMethod()
factoryMethod()
constructor()
op()
op()

8. Factory – sample code

9. Factory – comments
Factory methods are necessary for the OCP on object creation
Factory methods make the DIP more viable
Factory Method gives subclasses a hook for providing an extended version of an object
Creator could be a concrete class providing a default implementation of Product
Creator and Product could be the same class
There is an advantage of using a separate creator class for the product
The product and its creation are separate concerns
When the product is very complex, the creator can create products (even the first one) as demanded – lazy loading

10. Abstract Factory Design purpose Pattern summary
Provide an interface for creating families of related or dependent objects without specifying their concrete classes
Pattern summary
Capture family creation in a class containing a factory method for each class in the family

11. Abstract Factory – examples
Word processor for different window systems
Word processor is designed to a set of interfaces of graphical elements
Each windows system manufactures its own set of button, windows, dialogs, etc
Each installation of the word processor is given a windows system (concrete factory)
Kitchen showroom
The program is designed to a common set of cabinets, counters, etc
Each different style of kitchen furniture provide the furniture in the style (classic, contemporary, etc)
Each individual kitchen showroom is given a style (concrete factory)
GUI themes

12. Abstract Factory - structure
ProductA
ProductA1
ProductA2
Factory
+createProductA()
+createproductB()
Client
Factory1
+createProductA()
+createproductB()
Factory2
+createProductA()
+createproductB()
ProductB
ProductB1
ProductB2
ProductB createProductB {
Return new
ProductB1(); }
ProductA createProductA {
Return new
ProductA1(); }

13. Abstract Factory - participants
ProductA and ProductB
defines the interface of a family of objects.
ProductA1, ProductB1, ProductA2, and ProductB2
Two separate families of product implementation.
Factory
Defines the interface of the factory that returns the products
Factory1 and Factory2
Concrete factories that can produce products of the family.
Factory1 produces ProductA1 and ProductB1, Factory2 produces ProductA2 and ProductB2
Client
It depends only on the interfaces of the family products and the factory interface.
Collaborations
The client asks a subclass of Factory to create concrete products of ProductA and productB.

14. Abstract Factory – sample code

15. Abstract Factory – comments
Use the Abstract Factory when a client needs to use one of multiple families of products
It is hard to add new types of products since adding a new product means adding a new factory method to the AbstractFactory interface and its all subclasses
When families of products are different combinations of the same set of products and/or the # of families is large, many ConcreteFactory subclasses would be needed. In this case, the Prototype pattern may be employed

16. Prototype Design purpose Pattern summary
Create a set of almost identical objects whose type is determined at runtime
Pattern summary
Assume that a prototype instance is known; clone it whenever a new instance is needed

17. Prototype – examples Kitchen showroom
A showroom may have all cabinets in one style, counters in one style, etc
Instead of creating a factory for each possible combination of different furniture in different styles, each individual showroom is given a prototype of each type of furniture of a style
Each prototype can clone itself

18. Prototype - structure Prototype Client ConcreteProduct1
+clone()
+otherOperations()
prototype
Client
+anOperation()
ConcreteProduct1
+clone();
+otherOperations();
ConcreteProduct2
+cone();
+otherOperations();
Prototype p =
prototype.clone();
Return a copy of itself
Return a copy of itself

19. Prototype - participants
defines the interface (an operation) of cloning itself.
ConcreteProduct1 and ConcreteProduct2
Concrete objects that can clone themselves.
Client
Obtain more objects by asking them to clone themselves.
Collaborations
The client asks the prototype to clone itself for a new object of the prototype.

20. Shallow vs. deep cloning (coping)
prototype
ref
Client
+anOperation()
:Prototype
+clone()
-Nested:ref
:Nested
+op()
-data
prototype
ref
Client
+anOperation()
:Prototype
+clone()
-Nested:ref
:Nested
+op()
-data
ref
clone:Prototype
+clone()
-Nested:ref
Shallow cloning
prototype
ref
Client
+anOperation()
:Prototype
+clone()
-Nested:ref
:Nested
+op()
-data
ref
clone:Prototype
+clone()
-Nested:ref
clone:Nested
+op()
-data
Deep cloning

21. Shallow vs. deep cloning
//Shallow cloning: sample code
Class Prototype implements Cloneable {
private int x;
private Nested ref = new Nested();
public Prototype clone() {
Prototype p = new Prototype()
p.x = this.x;
p.ref = this.ref;
return p; }
Class Nested {
int data;
public void op() {}
Class Client {
private Prototype prototype =
new Prototype();
public void op() {
Prototype clone = prototype.clone();
// use clone
//Deep cloning: sample code
Class Prototype implements Cloneable {
private int x;
private Nested ref = new Nested();
public Prototype clone() {
Prototype p = new Prototype()
p.x = this.x;
p.ref = this.ref.clone();
return p; }
Class Nested implements Cloneable {
int data;
public void op() {}
public Nested clone() {
Nested n = new Nested()
n.data = this.data;
return n;
Class Client {
// the same Client as for Shallow cloning

22. Prototype – sample code

23. Prototype – comments
If the clone does not need to be identical as its original, a factory method may be used
Be aware of the shallow cloning problem – to the deepest level
When prototypes can be grouped in a small # of different combinations, the Abstract Factory may be suitable

24. Singleton Design purpose Pattern summary
Ensure there is exactly one instance of a class
Be able to obtain the instance from anywhere in the application
Pattern summary
Make the constructor of class private or protected, define a private static attribute of the class, define a public accessor to it.

25. Singleton – an example
A concrete factory in the Abstract Factory pattern in most cases should have only one instance – all objects are produced by the same factory
In JGrasp (or any IDE), we want one JVM (Singleton) for all Java programs.

26. Singleton - structure Singleton soleInstance +static getInstance();
+operations()
-data
soleInstance
<<static>>
return soleInstance;

27. Singleton - participants
Declare all constructors private and provide only one entry for obtaining a reference to the sole instance.
Client
Clients can get to the sole instance of Singleton by asking Singleton to return a reference to it.
Collaborations
A client can only call getInstance() to get a reference to the sole instance.
A client cannot create any instance of Singleton

28. Singleton – sample code
class Singleton {
// since private no client can access
// this reference directly
private static Singleton soleInstance
= new Singleton();
private int data;
// since protected, no client can
// create any instance directly
protected Singleton();
// the only entry for clients to get a
// reference to the sole instane
public static Singleton getInstance() {
return soleInstance; }
// other operations
public void operations() { }
class Client1 {
void anOperation() {
// Singleton ref = new Singleton();
// illegal since Singleton() is protected
Singleton ref = Singleton.getInstance();
ref.operations(); }
class Client2 {
// use ref
NOTE: objects of Client1 and Client2 would all share the same sole instance of Singleton.

29. Singleton – comments Lazy loading Not thread safe (Java)
If the object of Singleton is complex, it may take much resource to create. We better create the object only when it is referenced – lazy loading
Change the body of getInstance() with the following
if (soleInstance == null) {
soleInstance = new Singleton(); }
return soleInstance;
Not thread safe (Java)
Two concurrent threads could cause two instances created if executed concurrently
Solution: Make getInstance() synchronized
All static members?
Since there is only one instance, why don’t we just make all members static?
If yes, then the instance may not fit with the rest of the application: e.g., display(Employee) would not work if singleton CEO is all static

30. Builder Design purpose Pattern summary
Separate the construction of a complex object from its representation so that the same construction process can create different representations
Pattern summary
Use a builder to encapsulate the representation.

31. Builder – an example Language translator
Translate a Java programs to other programming languages (C++, Delphi)
The translation process is the same for all target languages – mapping “import” to something (“include” in C++)
Each target language has a builder to handle each keyword/structure

32. Builder - structure Builder builder Client Director BuilderA BuilderB
+buildPartA()
+buildPartB()
+buildPartC()
director
builder
Client
+madeProduct()
Director
+buildProduct()
BuilderA
+buildPartA()
+buildPartB()
+buildPartC()
+getProductA()
BuilderB
+buildPartA()
+buildPartB()
+buildPartC()
+getProductB()
For (every part needed in product)
if (part A)
builder.buildPartA();
else if (part B)
builder.buildPartB();
else if (part C)
builder.buildPartC(); }
ProductA
ProductB

33. Builder - participants
ProductA and ProductB
Concrete products that are created by different builders.
Director
A class that knows what steps it takes to build a product, but it does not know how each step is to be carried out or does not know how each part may be added to the final product
Builder
Defines an interface for concrete builders
BuildlerA and BuilderB
Concrete builders who know to construct each part of the product and add it to the final product
Client
A client selects a director and a concrete builder to build the product it needs. The client asks the concrete builder to return the final constructed product
Collaborations
The director knows what parts are needed for the final product and the selected concrete builder knows how to product the part and add it to the final product.

34. Builder – sequence diagram
Client
Director
Concrete
Builder
Product
builder = constructor()
constructor()
constructor(builder)
buildProduct()
buildPartA()
addPartA()
buildPartB()
addPartB()
buildPartC()
addPartC()
getProduct()

35. Builder – sample code Class Director { Class Product {
private Builder b;
Director(Builder b) {this.b = b;}
void buildProduct() {
for each part in Product {
if (partA) b.buildPartA();
else if (partB) b.buildPartB();
else if (partC) b.buildPartC(); }
client() {
Builder b = new ConcreteBuilder();
Director d = new Director(b);
d.buildProduct()
FinalProduct fp = b.getResult();
Class Product {
addPartA() {}
addPartB() {}
addPartC() {} … }
Class ConcreteBuilder
implements Builder {
Private: Product p;
ConcreteBuilder() {
p = new Product();
buildPartA() {… p.addParta(); … }
buildPartB() {… p.addPartb(); … }
buildPartC() {… p.addPartc(); … }
Product getResult() { return p; }

36. Creational design patterns
Factory
Abstract Factory
Prototype
Singleton
Builder