Scribd
Upload
13 views

Design Patterns: ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

The document discusses design patterns, which are reusable solutions to common software design problems. It provides examples of several design patterns, including observer, adapter, command, facade, composite, proxy, strategy, and bridge. The key aspects of each pattern are summarized, such as decoupling classes, providing a simplified interface, and separating interfaces from implementations. Design patterns help programmers reuse successful past designs and avoid reinventing solutions to recurring problems.

Uploaded by

yasser alali
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
13 views

Design Patterns: ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

The document discusses design patterns, which are reusable solutions to common software design problems. It provides examples of several design patterns, including observer, adapter, command, facade, composite, proxy, strategy, and bridge. The key aspects of each pattern are summarized, such as decoupling classes, providing a simplified interface, and separating interfaces from implementations. Design patterns help programmers reuse successful past designs and avoid reinventing solutions to recurring problems.

Uploaded by

yasser alali
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

Design Patterns

ECE 417/617: Stan Birchfield


Elements of Software Engineering Clemson University
What is a Design Pattern?
• A design pattern
– abstracts a recurring design structure
– comprises class and/or object
• dependencies,
• structures,
• interactions, or
• conventions
– distills design experience
Re-use
• Code re-use
– Don’t reinvent the wheel
– Requires clean, elegant, understandable, general,
stable code
– leverage previous work
• Design re-use
– Don’t reinvent the wheel
– Requires a precise understanding of common,
recurring designs
– leverage previous work
Some design patterns
• Abstract factory
• Adapter
• Bridge
• Command
• Composite
• Façade
• Subject / Observer
• Proxy
• Strategy
Subject-observer

[from Vlissides]
Subject-observer (cont.)

1 * Observer
Subject

Register(Observer) OnUpdate()
Unregister(Observer)
NotifyAll()

for all o in observers {


o.OnUpdate()
}
Subject-observer (cont.)
1 *
Subject Observer

Register(Observer) virtual OnUpdate()


Unregister(Observer)
NotifyAll() for all o in observers {
o.OnUpdate()
}

ConcreteSubject ConcreteObserver

virtual OnUpdate()
Model / view / controller (MVC)
View (displays data) {
Model m;
Controller (mediates) Controller c(&m);
View v(&c);
Model (holds data) } calls Register()

Main Create()
Create()

Register()
Create()

View

Controller

Model
MVC (cont.)
1 *
Subject Observer

Register(Observer) virtual OnUpdate()


Unregister(Observer)
NotifyAll() for all o in observers {
o.OnUpdate()
}

Controller View

virtual OnUpdate()
MVC (cont.)
class Observer
{
protected:
virtual void OnUpdate(MsgId message_id) = 0;
};

class Subject
{
public:
enum MsgId {};
void RegisterObserver(Observer* obs);
virtual void NotifyAllObservers(MsgId message_id) {
for (int i=0 ; i<m_observers.size() ; i++) {
m_observers[i]->OnUpdate(message_id);
}
}
private:
std::vector<Observer*> m_observers;
};
MVC (cont.)
class Controller : public Subject
{
Controller(Data* d) : m_data(d) {}
const Data* GetData() const;
void AddSphere(const Sphere& s) {
m_data->AddSphere(s);
NotifyAllObservers(ADD_SPHERE);
}
private:
Data* m_data;
};
MVC (cont.)
class MainWnd : public Observer
{
public:
MainWnd(Controller* c) : m_controller(c) {
c.Register(this);
}
virtual void OnUpdate(int message_id) {
switch (message_id) {
case Subject::ADD_SPHERE:
...
}
}
private:
Controller* m_controller;
};
Adapter
• You have
– legacy code
– current client
• Adapter changes interface of legacy code so
client can use it
• Adapter fills the gap b/w two interfaces
• No changes needed for either
– legacy code, or
– client
Adapter (cont.)
class NewTime
{
public:
int GetTime() {
return m_oldtime.get_time() * 1000 + 8;
}
private:
OldTime m_oldtime;
};
Command
• You have commands that need to be
– executed,
– undone, or
– queued
• Command design pattern separates
– Receiver from Invoker from Commands
• All commands derive from Command
and implement do(), undo(), and redo()
Facade
• You
– have a set of related classes
– want to shield the rest of the system from
these details
• Facade provides a simplified interface
• Encapsulates a subsystem
Composite
• You want uniformly to treat
– items (atomic elements), and
– groups (containing items or other groups)
• Composite interface specifies operations
that are shared between items and
groups
• Examples: hierarchy of files and
directories, groups of drawable elements
Composite (cont.)

Composite

Item Group
Proxy
• You want to
– delay expensive computations,
– use memory only when needed, or
– check access before loading an object into memory
• Proxy
– has same interface as Real object
– stores subset of attributes
– does lazy evaluation
Strategy
• You want to
– use different algorithms depending upon the context
– avoid having to change the context or client
• Strategy
– decouples interface from implementation
– shields client from implementations
– Context is not aware which strategy is being used;
Client configures the Context
– strategies can be substituted at runtime
– example: interface to wired and wireless networks
Strategy (cont.)
Client Policy

Context Strategy

Concrete Concrete
StrategyA StrategyB
Bridge
• You
– have several different implementations
– need to choose one, possibly at run time
• Bridge
– decouples interface from implementation
– shields client from implementations
– Abstraction creates and initializes the
ConcreteImplementations
– Example: stub code, slow code, optimized code
Bridge (cont.)
Client

Abstraction Implementor

Concrete Concrete
ImplementorA ImplementorB

Refined
Abstraction
Design pattern space

[from Vlissides]

You might also like