Design patterns

1
A Brief Introduction to Design
Patterns
Based on materials from Doug Schmidt

2
Object-oriented design
• OOD methods emphasize design notations
― Fine for specification, documentation
• But OOD is more than just drawing diagrams
― Good draftsmen, good designers
• Good OO designers rely on lots of experience
― At least as important as syntax
• Most powerful reuse is design reuse
Match problem to design experience
• OO systems exhibit recurring structures that
promote: abstraction, flexibility, modularity,
elegance

3
What is a design pattern?
• Codify design decisions and best practices
for solving recurring problems
― Not software libraries
― Not packaged solutions
― Templates that must be recognized and
adapted for a particular use

4
Four basic parts
1. Name
2. Problem
3. Solution
4. Trade-offs of application

6
Observer pattern components [1/2]

7
Observer pattern components [2/2]

8
Design patterns goals
• Codify good design
― distill & generalize experience
― aid to novices & experts alike
• Give design structures explicit names
― common vocabulary
― reduced complexity
― greater expressiveness
• Capture & preserve design information
― articulate design decisions succinctly
― improve documentation
• Facilitate restructuring/refactoring
― patterns are interrelated
― additional flexibility

9
GoF design patterns
Scope: domain over which a pattern applies
Purpose: reflects what a pattern does
GoF: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

10
Design pattern template [1/2]
• Intent
― short description of the pattern & its purpose
• Also Known As
― Any aliases this pattern is known by
• Motivation
― motivating scenario demonstrating pattern’s use
• Applicability
― circumstances in which pattern applies
• Structure
― graphical representation of the pattern using modified UML notation
• Participants
― participating classes and/or objects & their responsibilities

11
Design pattern template [2/2]
• Collaborations
― how participants cooperate to carry out their responsibilities
• Consequences
― the results of application, benefits, liabilities
• Implementation
― pitfalls, hints, techniques, plus language-dependent issues
• Sample Code
― sample implementations in C++, Java, C#, Smalltalk, C, etc.
• Known Uses
― examples drawn from existing systems
• Related Patterns
― discussion of other patterns that relate to this one

13
Observer design pattern [1/3]
Intent
― define a one-to-many dependency between objects so that when one object
changes state, all dependents are notified & updated
Applicability
― an abstraction has two aspects, one dependent on the other
― a change to one object requires changing untold others
― an object should notify unknown other objects
Structure

14
class ProxyPushConsumer : public // …
virtual void push (const CORBA::Any &event) {
for (std::vector<PushConsumer>::iterator i
(consumers.begin ()); i != consumers.end (); i++)
(*i).push (event);
}
class MyPushConsumer : public // ….
virtual void push
(const CORBA::Any &event) { /* consume the event. */ }

15
• Consequences
― modularity: subject & observers may vary independently
― extensibility: can define & add any number of observers
― customizability: different observers offer different views of subject
― unexpected updates: observers don’t know about each other
― update overhead: might need hints or filtering
• Implementation
― subject-observer mapping
― dangling references
― update protocols: the push & pull models
― registering modifications of interest explicitly
• Known Uses
― Smalltalk Model-View-Controller (MVC)
― InterViews (Subjects & Views, Observer/Observable)
― Pub/sub middleware (e.g., CORBA Notification Service, Java Messaging Service)
― Mailing lists

16
Benefits of design patterns
• Design reuse
• Uniform design vocabulary
• Enhance understanding, restructuring, &
team communication
• Basis for automation
• Transcends language-centric biases/myopia
• Abstracts away from many unimportant
details

17
Another example pattern: Template
Provides a skeleton of an algorithm in a method, deferring some steps to
subclasses (to avoid duplication)
class Base_Class {
public:
// Template Method.
void template_method (void) {
hook_method_1 ();
hook_method_2 ();
// ...
}
virtual void hook_method_1 () = 0;
virtual void hook_method_2 () = 0;
};
class Derived_Class_1 : public Base_Class {
virtual void hook_method_2 () { /* ... */ }
};
class Derived_Class_2 : public Base_Class {
};

18
Yet another design pattern: adapter [1/1]
• When two software components (e.g.,
legacy code and new development or a
COTS) cannot interface
• Adapter changes interface of one so the
other can use it
― Adapter fills the gap b/w two interfaces
― No changes needed for either

19
Yet another design pattern: adapter [2/2]
class NewTime
{
public:
int GetTime() {
return otime.get_time() * 100;
}
private:
OriginalTime otime;
};
An alternate: a wrapper

20
Relationship with other design
concepts

Design patterns

More Related Content

Similar to Design patterns (20)

Recently uploaded (20)

Design patterns