Creational Design Patterns Creational Design Patterns Structural Design Patterns Behavioral Design Patterns
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Creational Design Patterns
Creational Design Patterns
Structural Design Patterns
Behavioral Design Patterns
GoF Design Pattern Categories
Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter Interpreter
Template Method
Object Abstract Factory
Builder
Prototype
Singleton
Adapter
Bridge
Composite
Decorator
Facade
Proxy
Flyweight
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Creational Design Patterns
● Abstracts instantiation process
● Makes system independent of how its objects are
o created
o composed
o represented
● Encapsulates knowledge about which concrete classes the
system uses
● Hides how instances of these classes are created and put
together
Creational Design 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
● A class creational pattern uses inheritance to vary the class that's
instantiated, whereas an object creational pattern will delegate
instantiation to another object.
Creational Design Patterns
●Recurring themes:
oEncapsulate knowledge about which concrete
classes the system uses (so we can change them
easily later)
oHide 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
o InterViews GUI class library
oMultiple look-and-feels
o 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
Creational patterns
Because the creational patterns are closely related, we'll study all five of
them together to highlight their similarities and differences.
We'll also use a common example building a maze for a computer game
to illustrate their implementations.
The maze and the game will vary slightly from pattern to pattern.
We'll ignore many details of what can be in a maze and whether a maze
game has a single or multiple players.
Instead, we'll just focus o n how mazes get created.
We define a maze as a set of rooms.
A room knows its neighbors; possible neighbors are another room, a wall,
or a door to another room.
Creational patterns
The classes Room, Door, and Wall define the components of the maze
used in all our examples.
We define only the parts of these classes that are important for creating
a maze.
We'll ignore players, operations for displaying and wandering around in a
maze, and other important functionality that isn't relevant to building
the maze.
Creational patterns
Creational patterns
The class MapSite is the common abstract class for all the components
of a maze
class MapSite {
public:
virtual void Enter()=0
}
Creational patterns
Room is the concrete subclass of MapSite that defines the key
relationships between components in the maze.
It maintains references to other MapSite objects and stores a room
number. The number will identify rooms in the maze.
Enter provides a simple basis for more sophisticated game operations.
For example, if you are in a room and say "GoEast," the game can simply
determine which MapSite is immediately to the east and then call Enter
on it.
Creational patterns
class Room : public MapSite {
public:
Room(int roomNo);
MapSite* GetSide(Direction) const;
void SetSide(Direction, MapSite*);
virtual void Enter();
private:
MapSite* _sides[4];
int _roomNumber;
};
Creational patterns
The following classes represent the wall or door that occurs on each side of a room.
class Wall : public MapSite {
public:
Wall();
virtual void Enter();
};
class Door : public MapSite {
public:
Door(Room* = 0, Room* = 0);
virtual void Enter();
Room* OtherSideFrom(Room*);
private:
Room* _rooml;
Room* _room2;
bool _isOpen;
};
Creational patterns
We need to know about more than just the parts of a maze.
We'll also define a Maze class to represent a collection of rooms.
Maze can also find a particular room given a room number using its
RoomNo operation.
class Maze {
public:
Maze();
void AddRoom(Room* ) ;
Room* RoomNo(int) const;
private:
// . . .
};
Creational patterns
Another class is MazeGame, which creates the maze. One
straightforward way to create a maze is with a series of
operations that add components to a maze and then
interconnect them.
For example, the following member function will create a
maze consisting of two rooms with a door between them:
Creational patterns
Maze* MazeGame::CreateMaze () {
Maze* aMaze = new Maze;
Room* rl = new Room(l);
Room* r2 = new Ro om (2);
Door* theDoor = new Door(rl, r2);
aMaze->AddRoom(rl);
aMaze->AddRoom(r2);
rl->SetSide(North, new Wall);
rl->SetSide(East, theDoor);
rl->SetSide(South, new Wall);
rl->SetSide(West, new Wall);
r2->SetSide(North, new Wall);
r2->SetSide(East, new Wall);
r2->SetSide(South, new Wall);
r2->SetSide(West, theDoor);
return aMaze;
Creational patterns
The real problem with this member function isn't
its size but its inflexibility.
It hard-codes the maze layout.
Changing the layout means changing this member
function, either by overriding it—which means
reimplementing the whole thing—or by changing
parts of it—which is error-pronaend doesn't
promote reuse.
The creational patterns show how to make this
design more flexible, not necessarily smaller.
Abstract Factory (Object Creational)
IntentProvide an interface for creating families of related or
dependent objects without specifying their concrete classes
Pattern summaryCapture family creation in a class containing a factory
method for each class in the family
Also Known as
Kit
Abstract Factory - Motivation
1) Implement a user interface toolkit that supports multiple looks
and feel standards such as Motif, Windows 95 or the finder in
MacOS.
w How can you write a single user interface and make it portable
across the different look and feel standards for these window
managers?
2) Implement a facility management system for an intelligent
house that supports different control systems such as Siemens’
Instabus, Johnson & Control Metasys or Zumtobe’s proprietary
standard.
w How can you write a single control system that is independent
from the manufacturer?
Abstract Factory - Motivation
Different look-and-feels define different appearances and behaviors for user
interface "widgets" like scroll bars, windows, and buttons.
To be portable across look-and-feel standards, an application should not
hard-code its widgets for a particular look and feel.
Instantiating look-and feel specific classes of widgets throughout the
application makes it hard to change the look and feel later.
Abstract Factory - structure
Abstract Factory - structure
Abstract Factory The Client remains blissfully unaware of the various concrete classes in this
example. Client code deals with the simpler, abstract, general case.
Abstract Factory
Abstract Factory applicability
Use the Abstract Factory pattern 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.
• a family of related product objects is designed to be used together, and
you need to enforce this constraint.
• you want to provide a class library of products, and you want to reveal
just their interfaces not, their implementations.
Abstract Factory Participants
AbstractFactory (WidgetFactory)
- declares an interface for operations that create abstract product objects.
• ConcreteFactory (MotifWidgetFactory, PMWidgetFactory)
- implements the operations to create concrete product objects.
• AbstractProduct (Window, ScrollBar)
- declares an interface for a type o f product object.
• ConcreteProduct (MotifWindow, MotifScrollBar)
- defines a product object to be created by the corresponding concrete factory.
- implements the AbstractProduct interface.
• Client
- uses only interfaces declared by AbstractFactory and AbstractProductclasses.
Abstract Factory Collaborations
Normally a single instance of a Concrete Factory class is
created at run-time.
To create different product objects, clients should use a
different concrete factory.
Abstract Factory defers creation of product objects to its
Concrete Factory subclass.
Abstract Factory Consequences
●The Abstract Factory Pattern has the following benefits:
oIt isolates concrete classes from the client.
You use the Abstract Factory to control the classes
of objects the client creates.
Product names are isolated in the implementation of
the ConcreteFactory, clients use the instances
through their abstract interfaces.
Abstract Factory Consequences
oExchanging product families is easy.
None of the client code breaks because the abstract
interfaces don’t change.
Because the abstract factory creates a complete
family of products, the whole product family
changes when the concrete factory is changed.
oIt promotes consistency among products.
It is the concrete factory’s job to make sure that the
right products are used together.
Abstract Factory Consequences
● The Abstract Factory pattern has the following liability:
oAdding new kinds of products to existing factory is
difficult.
Adding a new product requires extending the
abstract interface which implies that all of its
derived concrete classes also must change.
Abstract Factory Consequences
Essentially everything must change to support and
use the new product family
abstract factory interface is extended
derived concrete factories must implement the
extensions
a new abstract product class is added
a new product implementation is added
client has to be extended to use the new product
Abstract Factory Implementation
Factories as singletons.
Creating the products.
Defining extensible factories.
Abstract Factory Implementation
● Concrete factories are often implemented as singletons.
● Creating the products
oConcrete factory usually use the factory method.
simple
new concrete factory is required for each product family
oalternately concrete factory can be implemented using
prototype.
only one is needed for all families of products
product classes now have special requirements - they
participate in the creation
Abstract Factory Implementation
● Defining extensible factories by using create function
with an argument
oonly one virtual create function is needed for the
AbstractFactory interface
oall products created by a factory must have the same
base class or be able to be safely coerced to a given
type
o it is difficult to implement subclass specific operations
UNIT-III
Know Uses
●Interviews
oused to generate “look and feel” for specific user
interface objects
ouses the Kit suffix to denote AbstractFactory classes,
e.g., WidgetKit and DialogKit.
oalso includes a layoutKit that generates different
composite objects depending on the needs of the
current context
ET++
oanother windowing library that uses the AbstractFactory
to achieve portability across different window systems
(X Windows and SunView).
L2
UNIT-III
Related Patterns
●Factory Method -- a “virtual” constructor
●Prototype -- asks products to clone
themselves
●Singleton -- allows creation of only a
single instance
L2
Related Documents
