Design PatternsDesign Patterns
6 March 20076 March 2007
National University of SingaporeNational University of SingaporeSchool 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
Design Patterns 6 March 2007 3
Origin of PatternOrigin of Pattern
Design Patterns 6 March 2007 4
Origin of PatternOrigin of Pattern
Design Patterns 6 March 2007 5
Origin of PatternOrigin of Pattern
Design Patterns 6 March 2007 6
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]
“
”
Design Patterns 6 March 2007 7
Origin of PatternOrigin of Pattern
• “A Pattern Language”– Berkeley architecture professor Christopher Al
exander in 1977– Patterns for
• City planning• Landscaping
– Architecture• In an attempt to capture
principles for “living” design
Design Patterns 6 March 2007 8
Example 167 (page 783) 6ft Example 167 (page 783) 6ft BalconyBalcony
Design Patterns 6 March 2007 9
History of History 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
Design Patterns 6 March 2007 10
History of History of Software Design PatternSoftware Design Pattern
• “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
Design Patterns 6 March 2007 11
Software Design PatternSoftware Design Pattern
………The design patterns in thi
s 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]
“
”
Design Patterns 6 March 2007 12
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.
Design Patterns 6 March 2007 13
Describing Design PatternsDescribing Design PatternsAlexandrian 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
Design Patterns 6 March 2007 14
Describing Design PatternsDescribing Design PatternsAlexandrian 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
Design Patterns 6 March 2007 15
Describing Design PatternsDescribing Design PatternsGoF 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
Design Patterns 6 March 2007 16
Describing Design PatternsDescribing Design PatternsGoF FormatGoF Format
• 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
Design Patterns 6 March 2007 17
Describing Design PatternsDescribing Design PatternsGoF FormatGoF Format
• 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 Patterns 6 March 2007 18
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 Patterns 6 March 2007 19
Design PatternDesign PatternSingletonSingleton
• 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
Design Patterns 6 March 2007 20
Design PatternDesign PatternSingletonSingleton
• 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
Design Patterns 6 March 2007 21
Design PatternDesign PatternSingletonSingleton
• Structure
Design Patterns 6 March 2007 22
Design PatternDesign PatternSingletonSingleton
• Participants– Singleton
• Collaborations– Clients access a Singleton instance
solely through Singleton’s Instance operation.
Design Patterns 6 March 2007 23
Design PatternDesign PatternSingletonSingleton
• 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
Design Patterns 6 March 2007 24
Design PatternDesign PatternSingletonSingleton
• Implementation - Java
Design Patterns 6 March 2007 25
Design PatternDesign PatternSingletonSingleton
• Known Uses– The set of changes to the code (ChangeSet curr
ent) in Smalltalk-80– The relationship between classes and metacla
sses– InterViews user interface toolkit to access the
unique instance of its Session and WidgetKit classes
Design Patterns 6 March 2007 26
Design PatternDesign PatternSingletonSingleton
• Related Patterns– Many patterns can be implemented
using the Singleton pattern– Abstract Factory– Builder– Prototype
Design Patterns 6 March 2007 27
Architectural PatternArchitectural Pattern
An architectural pattern expresses a fun
damental 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]
“
”
Design Patterns 6 March 2007 28
Architectural PatternArchitectural PatternLayersLayers
• Example – OSI 7-Layer Model
Design Patterns 6 March 2007 29
Architectural PatternArchitectural PatternLayersLayers
• 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
Design Patterns 6 March 2007 30
Architectural PatternArchitectural PatternLayersLayers
• 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
Design Patterns 6 March 2007 31
Architectural PatternArchitectural PatternLayersLayers
• Variants– Relaxed Layered System– Layering Through Inheritance
• Known Uses– Virtual Machines– APIs– Information Systems (IS)– Windows NT
Design Patterns 6 March 2007 32
Architectural PatternArchitectural PatternLayersLayers
• 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
Design Patterns 6 March 2007 33
Design Pattern Design Pattern RelationshipsRelationships
Design Patterns 6 March 2007 34
Pattern CatalogPattern Catalog
………a collection of related patt
erns, where patterns are subdivided into small number of broad categories………
- PATTERN-ORIENTED SOFTWARE ARCHITECTURE:A System of Patterns - Volume 1
[WILEY, 1996]
“
”
Design Patterns 6 March 2007 35
Core J2EE Pattern CatalogCore J2EE Pattern Catalog
Design Patterns 6 March 2007 36
Pattern SystemPattern System
A pattern system for software architectu
re is a collection of patterns for software architecture, together with guidelines for their implementation, combination and practical use in software development.
- PATTERN-ORIENTED SOFTWARE ARCHITECTURE:A System of Patterns - Volume 1
[WILEY, 1996]
“
”
Design Patterns 6 March 2007 37
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
Design Patterns 6 March 2007 38
Pattern System – POSA2Pattern System – POSA2
Design Patterns 6 March 2007 39
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.
Design Patterns 6 March 2007 40
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.
Design Patterns 6 March 2007 41
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.
Design Patterns 6 March 2007 42
ReferencesReferences
• 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.
Design Patterns 6 March 2007 43
ReferencesReferences
• 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.
Design Patterns 6 March 2007 44