cs6201 software reuse - design patterns

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


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 Al

exander in 1977– Patterns for

• City planning• Landscaping

– Architecture• In an attempt to capture

principles for “living” design


Example 167 (page 783) 6ft Example 167 (page 783) 6ft BalconyBalcony


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


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


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]

“

”


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


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


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



• 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 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



• 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



• Structure



• Participants– Singleton

• Collaborations– Clients access a Singleton instance

solely through Singleton’s Instance operation.



• 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



• Implementation - Java



• 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



• Related Patterns– Many patterns can be implemented

using the Singleton pattern– Abstract Factory– Builder– Prototype


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]

“

”


Architectural PatternArchitectural PatternLayersLayers

• Example – OSI 7-Layer Model



• 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



• 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



• Variants– Relaxed Layered System– Layering Through Inheritance

• Known Uses– Virtual Machines– APIs– Information Systems (IS)– Windows NT



• 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 Pattern Design Pattern RelationshipsRelationships


Pattern CatalogPattern Catalog

………a collection of related patt

erns, 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 architectu

re 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

Technology

pattern participants

pattern languages

standardization of pattern

use patterns

known names of pattern

reusable patterns

proven patterns

pattern andits application