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
