Design Patterns

Presented By:
Pankaj Sethia
 Design Patterns
General reusable solution to a commonly occurring problem
within a given context in software design.

A descriptions of communicating objects and classes that are

customized to solve a general design problem in a
particular context.

A pattern is made by four elements:

Name
Problem
Solution
Consequences
 Advantages of Design Pattern

Reusable object-oriented design.

Efficient.
Flexibility.
Extensibility.
Documentation.
Easy to propose ideas.
 Types of Design patterns
●
Creational Patterns
●
Structural Patterns
●
Behavioral Patterns
●
Concurrency Patterns
 Creational Pattern
●
Design patterns that deal with object creation
mechanisms, trying to create objects in a manner suitable
to the situation.
●
aim to separate a system from how its objects are created,
composed, and represented.
●
They increase the system's flexibility in terms of the what,
who, how, and when of object creation.
 Builder Pattern
●
Intention is to abstract steps of construction of
objects so that different implementations of
these steps can construct different
representations of objects.
●
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.
 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.
 Advantages
●
Simplify the construction of complex objects by only
specifying the type and content that the object
requires.
●
Allows different representations of the complex object
to be created by the different builders.
●
Each of the concrete builder objects will construct a
different representation of the complex object.
 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.
 Example
// "Product"
/ / "Abstract Builder"
class Pizza {
class PizzaBuilder {
Public:

void dough(const string& dough) {

public:
dough_ = dough; const Pizza& pizza() {
} return pizza_;
void sauce(const string& sauce) {
}
sauce_ = sauce;
virtual void buildDough() = 0;
}

void topping(const string& topping) { virtual void buildSauce() = 0;

topping_ = topping; virtual void buildTopping() = 0;
}
protected:
private:
Pizza pizza_;
string dough_;

string sauce_;
};
string topping_;

};
 Example Cont.
class HawaiianPizzaBuilder : public class SpicyPizzaBuilder : public
PizzaBuilder { PizzaBuilder {

public: public:

void buildDough() { void buildDough() {

pizza_.dough("cross"); pizza_.dough("pan baked");

}
}
void buildSauce() {
void buildSauce() {
pizza_.sauce("hot");
pizza_.sauce("mild");
}
}
void buildTopping() {
void buildTopping() {
pizza_.topping("pepperoni+salami");
pizza_.topping("ham+pineapple");
}
}
};
};
 Example Cont.
class Cook { const Pizza& getPizza() {
public: return pizzaBuilder_->pizza();
Cook()
}
: pizzaBuilder_(nullptr)
void constructPizza() {
{
pizzaBuilder_->buildDough();
}
~Cook() { pizzaBuilder_->buildSauce();
if (pizzaBuilder_) pizzaBuilder_->buildTopping();
delete pizzaBuilder_; }
} private:
void pizzaBuilder(PizzaBuilder* pizzaBuilder) { PizzaBuilder* pizzaBuilder_;
if (pizzaBuilder_)
};
delete pizzaBuilder_;
pizzaBuilder_ = pizzaBuilder;
}
 main
int main() {
Cook cook;
cook.pizzaBuilder(new HawaiianPizzaBuilder);
cook.constructPizza();
Pizza hawaiian = cook.getPizza();
hawaiian.open();
cook.pizzaBuilder(new SpicyPizzaBuilder);
cook.constructPizza();
Pizza spicy = cook.getPizza();
spicy.open();
}
 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.
 Singleton Pattern
• Intent
 Ensure a class only has one instance, and provide a
global point of access to it.
• Motivation
 It’s important for some classes to have exactly one
instance.
 Although there can be many printers in a system, there
should be only one printer spooler.
 There should be only one file system (or file system
manager) and one window manager.
 Singleton Structure

Singleton

static Instance()
SingletonOperation()
GetSingletonData() return uniqueinstance

static uniqueinstance
singletonData
 Example
bool Singleton::instanceFlag = false;
cass Singleton
Singleton* Singleton::single = NULL;
{
Singleton* Singleton::getInstance()
private:
{
static bool instanceFlag;
if(! instanceFlag)
static Singleton *single;
{
Singleton()
single = new Singleton();
{
instanceFlag = true;
//private constructor
return single;
}
}
public:
else
static Singleton* getInstance();
{
void method();
return single;
~Singleton()
}
{
}
instanceFlag = false;
void Singleton::method()
}
{
};
cout << "Method of the singleton class" << endl;

}
 main
int main()
{
Singleton *sc1,*sc2;
sc1 = Singleton::getInstance();
sc1->method();
sc2 = Singleton::getInstance();
sc2->method();

return 0;
}
Where can we use these patterns in
OSAL

Singleton pattern
Builder pattern
Any Question ???