Scribd
Upload
36 views

A Brief Introduction To Design Patterns: Based On Materials From Doug Schmidt

The document introduces design patterns as codified best practices for solving common programming problems. It discusses that object-oriented design relies on experience and recurring structures. A design pattern describes a problem, solution, and consequences of applying the solution. The Observer pattern is provided as an example, with its components and role of allowing one-to-many dependency so objects can update when a shared object's state changes. Design patterns provide benefits like reuse, vocabulary, and abstraction.

Uploaded by

Piyush kukade
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
36 views

A Brief Introduction To Design Patterns: Based On Materials From Doug Schmidt

The document introduces design patterns as codified best practices for solving common programming problems. It discusses that object-oriented design relies on experience and recurring structures. A design pattern describes a problem, solution, and consequences of applying the solution. The Observer pattern is provided as an example, with its components and role of allowing one-to-many dependency so objects can update when a shared object's state changes. Design patterns provide benefits like reuse, vocabulary, and abstraction.

Uploaded by

Piyush kukade
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 20

A Brief Introduction to Design

Patterns

Based on materials from Doug Schmidt

1
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

2
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

3
Four basic parts

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

4
Example: Observer pattern

5
Observer pattern components [1/2]

6
Observer pattern components [2/2]

7
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

8
GoF design patterns
GoF:  Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

Scope: domain over which a pattern applies


Purpose: reflects what a pattern does

9
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

10
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

11
UML/OMT notation

12
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

13
Observer design pattern [2/3]

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. */ }

14
Observer design pattern [3/3]
• 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

15
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

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


virtual void hook_method_1 () { /* ... */ }
virtual void hook_method_2 () { /* ... */ }
};

17
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

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

An alternate: a wrapper

19
Relationship with other design
concepts

20

You might also like