1) Design patterns abstract recurring design structures comprising classes and objects to distill design experience and enable design reuse without reinventing solutions. 2) Common design patterns include abstract factory, adapter, bridge, command, composite, facade, observer, proxy, strategy, and model-view-controller (MVC). 3) The document provides examples of how each pattern addresses common software design problems to improve flexibility, reuse, and understanding of code.

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

2. 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

3. 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

4. Some design patterns
• Abstract factory
• Adapter
• Bridge
• Command
• Composite
• Façade
• Subject / Observer
• Proxy
• Strategy

5. Subject-observer
[from Vlissides]

6. Subject-observer (cont.)
Subject
Register(Observer)
Unregister(Observer)
NotifyAll()
Observer
OnUpdate()
1 *
for all o in observers {
o.OnUpdate()
}

7. Subject-observer (cont.)
Subject
Register(Observer)
Unregister(Observer)
NotifyAll()
Observer
virtual OnUpdate()
1 *
for all o in observers {
o.OnUpdate()
}
ConcreteSubject ConcreteObserver
virtual OnUpdate()

8. Model / view / controller (MVC)
Controller
Model
View (displays data)
(mediates)
(holds data)
{
Model m;
Controller c(&m);
View v(&c);
} calls Register()
Main
View
Controller
Model
Create()
Create()
Create()
Register()

9. MVC (cont.)
Subject
Register(Observer)
Unregister(Observer)
NotifyAll()
Observer
virtual OnUpdate()
1 *
for all o in observers {
o.OnUpdate()
}
Controller View
virtual OnUpdate()

10. 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;
};

11. 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;
};

12. 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;
};

13. 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

14. Adapter (cont.)
class NewTime
{
public:
int GetTime() {
return m_oldtime.get_time() * 1000 + 8;
}
private:
OldTime m_oldtime;
};

15. 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()

16. 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

17. 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

18. Composite (cont.)
Group
Item
Composite

19. 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

20. 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

21. Strategy (cont.)
Client
Strategy
Concrete
StrategyA
Concrete
StrategyB
Context
Policy

22. 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

23. Bridge (cont.)
Client
Implementor
Refined
Abstraction
Concrete
ImplementorA
Concrete
ImplementorB
Abstraction

24. Design pattern space
[from Vlissides]