CS6201 Software Reuse - Design Patterns

Design PatternsDesign Patterns
6 March 20076 March 2007
National University of SingaporeNational University of Singapore
School of ComputingSchool of Computing
OH KWANG SHINOH KWANG SHIN

Design Patterns 6 March 2007 2
AgendaAgenda
• Origin of Pattern
• Software Design Patterns
• Why Use Patterns?
• Describing Design Patterns
• Architectural Pattern
• Pattern System
• Drawbacks of Patterns

Origin of PatternOrigin of Pattern


Each pattern describes a problem which
occurs over and over again in our
environment, and then describes the core of
the solution to that problem, in such a way that
you can use this solution a million times over,
without ever doing it the same way twice
- Christopher Alexander (Architect) [AIS+
77, page x]
“
”

• “A Pattern Language”
– Berkeley architecture professor
Christopher Alexander in 1977
– Patterns for
• City planning
• Landscaping
– Architecture
• In an attempt to capture
principles for “living” design

Example 167 (page 783)Example 167 (page 783)
6ft Balcony6ft Balcony

History ofHistory of
Software Design PatternSoftware Design Pattern
• “Using Pattern Languages for Object-
Oriented Programs”
– Kent Beck and Ward Cunningham,
Tektronix, Inc.
– OOPSLA-87 Workshop
– Used Alexander’s “Pattern” ideas for
designing window-based user interfaces
– Lack of the concrete illustration

History ofHistory of
• “Design Patterns: Elements of
Reusable Object-Oriented Software”
– Erich Gamma, Richard Helm,
Ralph Johnson, John Vlisssides
– GoF – “Gang of Four”
– Standardization of Pattern
– Four essential elements of Pattern
• Pattern Name, Problem,
Solution, Consequences


………The design patterns in this
book are descriptions of communicating
objects and classes that are customized
to solve a general design problem in a
particular context. ………
- Design Patterns:
Elements of Reusable Object-Oriented Software
[Addison Wesley, 1995]
“
”

Why Use Patterns?Why Use Patterns?
• Proven
– Patterns reflect the experience, knowledge and
insights of developers who have successfully
used these patterns in their own work.
• Reusable
– Patterns provide a ready-made solution that
can be adapted to different problems as
necessary.
• Expressive
– Patterns provide a common vocabulary of
solutions that can express large solutions
succinctly.

Describing Design PatternsDescribing Design Patterns
Alexandrian FormAlexandrian Form
• Name
– meaningful name
• Problem
– the statement of the problem
• Context
– a situation giving rise to a problem
• Forces
– a description of relevant forces and constraints
• Solution
– proven solution to the problem

Alexandrian FormAlexandrian Form
• Examples
– sample applications of the pattern
• Resulting context (force resolution)
– the state of the system after
pattern has been applied
• Rationale
– explanation of steps or rules in the pattern
• Related patterns
– static and dynamic relationship
• Known use
– occurrence of the pattern and
its application within existing system

GoF FormatGoF Format
• Pattern Name and Classification
• Intent
– what does pattern do / when the
solution works
• Also Known As
– other known names of pattern (if any)
• Motivation
– the design problem / how class and
object structures solve the problem

• Applicability
– situations where pattern can be applied
• Structure
– a graphical representation of classes in the
pattern
• Participants
– the classes/objects participating and their
responsibilities
• Collaborations
– how the participants collaborate to carry out
responsibilities

• Consequences
– trade-offs, results, concerns
• Implementation
– hints, techniques
• Sample Code
– code fragment showing possible
implementation
• Known Uses
– patterns found in real systems
• Related Patterns
– closely related patterns

Design Pattern SpaceDesign Pattern Space
Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter (class) Interpreter
Template Method
Object Abstract Factory
Builder
Prototype
Singleton
Adapter (object)
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

Design PatternDesign Pattern
SingletonSingleton
• Intent
– Ensure a class only has one instance,
and provide a global point of access to
it.
• Motivation
– Although there can be many printers in
a system, there should be only one
printer spooler
– There should be only one file system
and one window manager

SingletonSingleton
• Applicability
– There must be exactly one instance of a
class, and it must be accessible to
clients from a well-known access point
– When the sole instance should be
extensible by subclassing, and clients
should be able to use an extended
instance without modifying their code

SingletonSingleton
• Structure

SingletonSingleton
• Participants
– Singleton
• Collaborations
– Clients access a Singleton instance
solely through Singleton’s Instance
operation.

SingletonSingleton
• Consequences
– Controlled access to sole instance
– Reduced name space
– Permits refinement of operations and
representation
– Permits a variable number of instances
– More flexible than class operations

SingletonSingleton
• Implementation - Java

SingletonSingleton
• Known Uses
– The set of changes to the code
(ChangeSet current) in Smalltalk-80
– The relationship between classes and
metaclasses
– InterViews user interface toolkit to
access the unique instance of its Session
and WidgetKit classes

SingletonSingleton
• Related Patterns
– Many patterns can be implemented
using the Singleton pattern
– Abstract Factory
– Builder
– Prototype

Architectural PatternArchitectural Pattern

An architectural pattern expresses a
fundamental structure organization schema for
software systems. It provides a set of predefined
subsystems, specifies their responsibilities, and
includes rules and guidelines for organizing the
relationships between them.
- PATTERN-ORIENTED SOFTWARE ARCHITECTURE:
A System of Patterns - Volume 1
[WILEY, 1996]
“
”

LayersLayers
• Example – OSI 7-Layer Model

LayersLayers
• Context
– A large system that requires decomposition
• Problem
– The system we are building is divided by mix
of low- and high-level issues, where high-level
operations reply on the lower-level ones
• Solution
– Structure your system into an appropriate
number of layers and place them on top of
each other

LayersLayers
• Structure
– An individual layer can be described by the
following CRC card:
Class Collaborator
Layer J  Layer J-1
Responsibility
 Provides services
Used by Layer J+1
 Delegates subtasks
to Layer J-1
Class Collaborator
Layer J  Layer J-1
Responsibility
 Provides services
Used by Layer J+1
 Delegates subtasks
to Layer J-1

LayersLayers
• Variants
– Relaxed Layered System
– Layering Through Inheritance
• Known Uses
– Virtual Machines
– APIs
– Information Systems (IS)
– Windows NT

LayersLayers
• Consequences
– Benefits
• Reuse of layers
• Support for standardization
• Dependencies are kept local
• Exchangeability
– Liabilities
• Cascades of changing behavior
• Lower efficiency
• Unnecessary work
• Difficulty of establishing the correct granularity of
layers

RelationshipsRelationships

Pattern CatalogPattern Catalog

………a collection of related
patterns, where patterns are
subdivided into small number of
broad categories………
[WILEY, 1996]
“
”

Core J2EE Pattern CatalogCore J2EE Pattern Catalog

Pattern SystemPattern System

A pattern system for software architecture
is a collection of patterns for software architecture,
together with guidelines for their implementation,
combination and practical use in software
development.
[WILEY, 1996]
“
”

Pattern SystemPattern System
• Motivation
– Individual patterns & pattern catalogs are
insufficient
• Benefits
– Define a vocabulary for talking about
software development problems
– Provide a process for the orderly resolution of
these problems
– Help to generate & reuse software
architectures

Pattern System – POSA2Pattern System – POSA2

Drawbacks of PatternsDrawbacks of Patterns
• Pattern is not a Silver Bullet!
• Patterns do not lead to direct code reuse.
• Individual Patterns are deceptively simple.
• Composition of different patterns can be
very complex.
• Teams may suffer from pattern overload.
• Patterns are useful starting points,
but they are not destinations.

Drawbacks of PatternsDrawbacks of Patterns
• Patterns are validated by experience
and discussion rather than by
automated testing.
• Integrating patterns into a software
development process is a human-
intensive activity.

ReferencesReferences
• Douglas Schmidt and Frank Buschmann, “Patterns, Frameworks,
and Middleware: Their Synergistic Relationships” Proceedings of
25th
International Conference on Software Engineering, 2003.
• E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software. MA: Addison-
Wesley, 1995.
• C. Alexander, The Timeless Way of Building. New York, NY:
Oxford University Press, 1979.
• C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-
King, and S. Angel, A Pattern Language. New York, NY: Oxford
University Press, 1977.

• Kent Beck and Ward Cunningham, “Using Pattern Languages for
Object-Oriented Programs” Submitted to the OOPSLA-87
workshop on the Specification and Design for Object-Oriented
Programming. Available: http://c2.com/doc/oopsla87.html
• J2EE Design Patterns.
Available: http://java.sun.com/blueprints/patterns/index.html
• Douglas C. Schmidt’s Home Page.
Available: http://www.cs.wustl.edu/~schmidt/
• Design pattern – Wikipedia, the free encyclopedia.
Available: http://en.wikipedia.org/wiki/Design_pattern
• Frank Buschmann, Regine Meunier, Hans Rohnert, Peter
Sommerlad, Michael Stal, PATTERN-ORIENTED SOFTWARE
ARCHITECTURE - A System of Patterns. New York: WILEY,
1996.

• DEEPAK ALUR, JOHN CRUPI, DAN MALKS, CORE J2EE
PATTERNS – Best Practices and Design Strategies. Prentice Hall
PTR, 2001.
• Martin Fowler, PATTERNS OF ENTERPRISE APPLICATION
ARCHITECTURE. Addison-Wesley, 2003.
• GREGOR HOHPE, BOBBY WOOLF, ENTERPRISE
INTEGRATION PATTERNS – DESIGNING, BUILDING, AND
DEPLOYING MESSAGING SOLUTIONS. Addison-Wesley, 2004.

CS6201 Software Reuse - Design Patterns

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to CS6201 Software Reuse - Design Patterns

Similar to CS6201 Software Reuse - Design Patterns (20)

More from Kwangshin Oh

More from Kwangshin Oh (7)

Recently uploaded

Recently uploaded (20)

CS6201 Software Reuse - Design Patterns

Editor's Notes