Creational Design Patterns:

Elements of Reusable Object

Oriented Software

Suganthy. A
1

Design Pattern

Creational Patterns
Protoptype
Builder
Abstract Factory
Factory Method
singleton
Bibliography

Design Patterns

Creational Pattern

Singleton

Ensure a class only has one instance

Provide a global point of access to it

Abstract Factory:

Provide an interface for creating families of

related or dependent objects without specifying
their concrete classes

Design Patterns

Creational Pattern

Factory Method:

Define an interface for creating an object but

let subclasses decide which class to
instantiate
Lets a class defer instantiation to subclasses

Prototype

Specify the kinds of objects to create using a

prototypical instance
Create new objects by copying this prototype

Design Patterns

Creational Pattern

Builder:

Separate the construction of a complex object

from its representation so that the same
construction process can create different
representations

Design Patterns

Singleton Pattern

Intent
Ensure a class only has one instance,
and provide a global point of access to
it.
Motivation

we need to have exactly only one instance for a

class (ex. Printer spooler)
Make the class itself responsible for keeping
track of its sole instance
The class provide a way to access the instance

Applicability

There must be only one instance of a class

accessible from a well-known point
Design Patterns

Singleton Pattern

Structure

Singleton
Return
uniqueInstance

Static Instance()

SingletonOperation()
GetSingletonData()
Static uniqueInstance
SingletonData

Design Patterns

Singleton Pattern

Participants

Collaborations

Singleton class
Access only through Singletons instance
operation

Consequences

Controlled access to sole instance

Permits refinement of operation and
representation
More flexible than class operations
Reduced name space

Design Patterns

Example of Singleton use

We had to have only one instance for class

Director. We simply solve our problem
using Singleton Pattern
Director
Static Instance()
Given(n_ticket:int):void
Error():void
Static UniqueInstance

Design Patterns

Singleton
class Singleton {

// Only one instance can ever be created.

public:
static Singleton* Instance();
protected:
Singleton();

// Creation hidden inside Instance().

private:
Static Singleton* _instance
}
// Cannot access directly.

Design Patterns

10

Singleton
Singleton* Singleton::_instance=0;

Singleton* Singleton:: Instance(){

if (_instance ==0) {
_instance=new Singleton;
}
Return _instance;
}
// Clients access the singleton
// exclusively via the Instance member
// function.

11

Singleton

Related Pattern
Abstract Factory
Builder
Prototype

Design Patterns

12

Abstract Factory

Intent
Provide an interface for creating
families of related or dependent
objects without specifying their
concrete classes

Also known as
Kit

Design Patterns

13

Abstract Factory

Motivation (Problem)
Consider a user interface toolkit to
support multiple look-and-feel
standards.
For portability an application must not
hard code its widgets for one look and
feel.
How to design the application so that
incorporating new look and feel
requirements will be easy?

Design Patterns

14

Abstract Factory

Solution
1.
2.

3.

Define an abstract WidgetFactory class.

This class declares an interface to create different kinds
of widgets.
There is one abstract class for each kind of widget and
concrete subclasses implement widgets for different
standards.

4.

WidgetFactory offers an operation to return a new widget

object for each abstract widget class. Clients call these
operations to obtain instances of widgets without being aware of
the concrete classes they use.
Design Patterns

15

Abstract Factory
WidgetFactory

Client
Window

CreateScrollbar()
CreateWindow()
MacWindow

WWindow

ScrollBar

WWidgetFactory

MacWidgetFactory

MacScrollBar
One for each standard.
Design Patterns

WScrollBar

16

Abstract Factory
Participants and Communication

AbstractFactory: Declares the interface for operations to

create abstract product objects

ConcreteFactory: Implements the operations to create concrete

product objects.

AbstractProduct: Declares an interface for a type of product object.

ConcreteProduct: Defines a product object to be created by the

corresponding factory.

Client: Uses only the interface declared by the abstractFactory and

AbstractProduct classes.
Design Patterns

17

Factory Method

Intent
Define an interface for creating an
object, but let subclasses decide which
class to instantiate.
Factory method lets a class defer
instantiation to subclasses.
Also Known as
Virtual constructor

Design Patterns

18

Factory Method

Motivation (The problem)

1. Frameworks use abstract classes to define and maintain
relationships between objects
2. Consider a framework for applications that present multiple
documents to the user. A drawing application is an example.
3. This framework defines two abstract classes: application and
document. These ought to be sub classed by clients for application
specific implementation.
4. The application class will create and manage documents when
required, e.g. when a New command is selected from the menu.

Design Patterns

19

Factory Method

5. Document sub class is application specific. Hence the Application

class does not know what kind of document to create!
6. Problem: The framework must instantiate classes but it only
knows about the abstract classes, which it cannot initiate!

Design Patterns

20

Factory Method

The Solution
1.

The Factory Method pattern encapsulates the knowledge

of which Document subclass to create and moves this
knowledge out of the framework.

2.

Application subclasses redefine an abstract CreateDoc()

method to return the appropriate Document subclass.

3. When an Application is instantiated, it can instantiate

application specific Documents without knowing their
class.

Design Patterns

21

Factory Method
Factory method
docs
Document

Application
*

Open()
Close()

1
CreateDoc()
NewDoc()
OpenDoc()

Save()

MyApplication

MyDocument

CreateDoc()

Document* doc=CreateDoc();
docs.Add(doc);
docOpen();

Design Patterns

22

Factory Method
Structure of Factory Method

Creator

Product

FactoryMethod()
SomeOperation()
product=Factory method
ConcreteCreator
FactoryMethod()

ConcreteProduct

Return new ConcreteProduct

Design Patterns

23

Factory Method
Participants and Communications

Product (Document): Defines the interface of objects the factory method creates.

ConcreteProduct (MyDocument): Implements the Product interface.

Creator (Application): Declares factory method which returns an object of type Product. Also,
may define the factory method to create a Product object.

ConcreteCreator (MyApplication): Overrides the factory method to return an instance of a

ConcreteProduct.

Design Patterns

24

Builder

Intent
The Builder Pattern separates the
construction of a complex object from
its representation so that the same
construction process can create
different representations.

Design Patterns

25

Builder

Structure

Design Patterns

26

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. Also, it defines and keeps
track of the representation it creates and
provides an interface for retrieving the
product .
Director - constructs an object using the
Builder interface.
Product - represents the complex object under
construction.

Design Patterns

27

Builder

Collaborations

The client creates the Director object and

configures it with the desired Builder object.

Director notifies the builder whenever a part of
the product should be built.
Builder handles requests from the director and
adds parts to the product.
The client retrieves the product from the
builder.

Design Patterns

28

Builder

Design Patterns

29

Builder

Use he Builder pattern when:

The algorithm for creating a complex
object should be independent of the parts
that make up the object and how they are
assembled.
The
construction
process
must
allow
different representations for the object
that is constructed.

Design Patterns

30

Builder

Consequences
A Builder lets you vary the internal

representation of the product it builds. It

also hides the details of how the product is
assembled.
Each specific builder is independent of the
others and of the rest of the program. This
improves modularity and makes the addition of
other builders relatively simple.
Because each builder constructs the final
product step-by-step, depending on the data,
you have more control over each final product
that a Builder constructs.

Design Patterns

31

Builder

A Builder pattern is somewhat like an Abstract

Factory pattern in that both return classes made
up of a number of methods and objects. The main
difference is that while the Abstract Factory
returns a family of related classes, the Builder
constructs a complex object step by step
depending on the data presented to it.

Related Patterns
Abstract Factory
Composite

Design Patterns

32

Prototype

Intent
Specify the kinds of objects to create
using a prototypical instance, and
create new objects by copying (cloning)
this prototype.

Design Patterns

33

Prototype

Structure

Design Patterns

34

Prototype

Participants
Prototype(Graphic)
Declares an interface for cloning
itself
ConcretePrototype (Staff, wholeNote,
HalfNote)
Implements an operation for cloning
itself.
Client(GraphicalTool)
Creates a new object by asking a
prototype to clone itself
Design Patterns

35

Prototype

Applicability
The prototype pattern is used when a
system should be independent of how its
products are created, composed, and
represented;
[i.e., concrete product classes are
hidden from client - similar to Builder
or Abstract Factory]

Design Patterns

36

Prototype

when the classes to instantiate are

specified at run-time; for example,
through dynamic loading; OR
to avoid building a class hierarchy of
factories that parallels the class
hierarchy of products; OR
when instances of a class can have one of
only a few different combinations of state

Design Patterns

37

Prototype

Consequences
Isolating concrete product classes from
the client.
Dynamically adding and removing product
classes at run-time.
Specifying new predefined objects by
varying values/varying structure.
Reducing the need for sub-classing.
Configuring an application with classes
dynamically.
Main possible liability: Clone() needed.

Design Patterns

38

Bibliography

Erich Gamma, Richard Helm,Ralph

Johnson,John Vlissides. Design Patterns:
Elements of Reusable Object-Oriented
Software. ADDISON-WESLEY 1995

Design Patterns

39