Design Patterns: History,

Motivation and Concepts

Master (of Engineering) in Computer Science
Course overview
• Motivation & Concepts
• The issue
• What patterns & frameworks are
• What they’re good for
• How we develop & categorize them

Component 2
Overview of frameworks
• Frameworks provide integrated domain-specific structures & functionality
• Frameworks are “semi-complete” applications
• Definition
• “..an integrated set of software artefacts (such as classes, objects and components)
that collaborate to provide a reusable architecture for a family of related
applications.”
• Extending the framework involves
• Adding concrete classes that inherit operations from abstract classes in the
framework;
• Adding methods that are called in response to events that are recognized by the
framework.

Component 3
Categories of OO frameworks
• White-box frameworks are reused by subclassing, which usually
requires understanding the implementation of the framework to
some degree
• Black-box framework is reused by parameterizing & assembling
framework objects, thereby hiding their implementation from users
• Each category of OO framework uses different sets of patterns
• Black-box frameworks reply heavily on object composition patterns, such as
Strategy & Decorator
• White-box frameworks rely heavily on inheritance-based patterns, such as
Template Method & State

Component 4
Benefits of framework
• Design reuse
• e.g., by guiding application developers through the steps necessary to ensure
successful creation & deployment of software
• Implementation reuse
• e.g., by amortizing software lifecycle costs & leveraging previous
development & optimization efforts
• Validation reuse
• e.g., by amortizing the efforts of validating application- & platform-
independent portions of software, thereby enhancing software reliability &
scalability

Component 5
Limitations of frameworks
• Frameworks are powerful, but can be hard to use effectively (& even
harder to create) for many application developers
• Commonality & variability analysis requires significant domain knowledge &
OO design/implementation expertise
• Significant time required to evaluate applicability and quality of a
framework for a particular domain
• Debugging is tricky due to inversion of control
• V&V is tricky due to “late binding”
• May incur performance degradations due to extra (unnecessary)
levels of indirection

Component 6
So …
• A framework is an integrated set of classes that collaborate to form a
reusable architecture for a family of applications
• Frameworks implement pattern languages
• Patterns are micro-architectures, independent from a particular
application and a specific language/technology

Component 7
History of Design Pattern
• 1979: Christopher Alexander, architect, “The Timeless Way of
Building”,Oxford Press
• 1987:OOPSLA (Object Oriented Programming System),Orlando,
presentation of design pattern to the community OO by Ward
Cunningham and Kent Beck
• 1995:Group of Four alias E.Gamma, R.Helm,R.Johnson and J.Vlissides :
“Design Pattern:Elements of Reusable OO software”

Component 8
Motivation
• OOD methods emphasize design notations
• Fine for specification & documentation
• But OOD is more than just drawing diagrams
• Good draftsmen are not necessarily good architects!
• Good OO designers rely on lots of experience
• At least as important as syntax
• Most powerful reuse combines design & code reuse
• Patterns: Match problem to design experience
• Frameworks: Reify patterns within a domain context

Component 9
Recurring structure
• Well-designed OO systems exhibit recurring structures that promote
• Abstraction
• Flexibility
• Modularity
• Elegance
• Problem
• capturing, communicating, applying, and preserving this knowledge without
undue time, effort, and risk

Component 10
A Pattern
• Abstracts & names a recurring design structure
• Comprises class and/or object
• Dependencies
• Structures
• Interactions
• Conventions
• Specifies the design structure explicitly
• Is distilled from actual design experience
• Presents solution(s) to common (software) problem(s) arising within
a context

Component 11
Basic Parts of a Pattern
• A pattern is made by four elements
1. Name
2. Problem (including “forces” & “applicability”)
3. Solution
• both visual & textual descriptions
4. Consequences and trade-offs of applying the pattern
• Key characteristics of patterns include:
• Language-independent
• implementation-independent
• “Micro-architecture,” i.e., “society of objects”
• Adjunct to existing methodologies (RUP, Fusion, SCRUM, etc.)

Component 12
Name
• Describe a design problems and its solutions in a word or two
• Used to talk about design pattern with our colleagues
• Used in the documentation
• Increase our design vocabulary
• Have to be coherent and evocative

Component 13
Problem and Solution
• Problem
• Describes when to apply the patterns
• Explains the problem and its context
• Sometimes include a list of conditions that must be met before it makes sense
to apply the pattern
• Have to occurs over and over again in our environment
• Solution
• Describes the elements that make up the design, their relationships,
responsibilities and collaborations
• Does not describe a concrete design or implementation
• Has to be well proven in some projects
• UML-like structure, abstract code
Component 14
Consequences
• Results and trade-offs of applying the pattern
• Helpful for describe design decisions, for evaluating design
alternatives
• Benefits of applying a pattern
• Impacts on a system’s flexibility, extensibility or portability

Component 15
Pattern description
• Pattern name and classification
• contains the essence of pattern succinctly
• Become part of your design vocabulary
• Intent
• What does the pattern do ?
• What particular problem does it address ?
• Motivation
• Illustrate a design problem and how the class and the object structures solve the
problem
• Applicability
• In which situations the pattern can be applied?
• How can you recognize these situations?
Component 16
Pattern description…
• Structure
• Graphical representation of the classes and their collaborations in the pattern (UML
is often used)
• Participants
• Class
• Objects
• Responsibilities
• Collaborations
• How the participants collaborate to carry out their responsibilities
• Consequences
• How does the pattern support its objectives?
• What are the trade-offs and results of using the pattern?
Component 17
Pattern description
• Implementation
• pitfalls, hints, techniques, plus language-dependent issues
• Sample Code
• sample implementations in C++, Java, C#, Smalltalk, C, etc
• Known Uses
• Examples of the pattern found in real (from existing) systems
• Related Patterns
• What design patterns are closely related to this one?
• What are the important differences?

Component 18
Design Space for GoF Patterns

√ √ √
√

√
√ √ √
√ √ √
√
√
√ √
√
√

Scope: domain over which a pattern applies

Purpose: reflects what a pattern
Component does 19
Creational Pattern
• Abstract the instantiation process
• Make a system independent to its realization
• Class Creational use inheritance to vary the instantiated classes
• Object Creational delegate instantiation to another object

Component 20
Structural & behavioral patterns
• Structural
• Class Structural patterns concern the aggregation of classes to form largest
structures
• Object Structural pattern concern the aggregation of objects to form largest
structures
• Behavioral
• Concern with algorithms and assignment of responsibilities between objects
• Describe the patterns of communication between classes or objects
• Behavioral class pattern use inheritance to distribute behavior between
classes
• Behavioral object pattern use object composition to distribute behavior
between classes

Component 21
Pattern vs Framework
• Design patterns are more abstract than frameworks
• Design patterns are smaller architectural elements than frameworks
• Design patterns are less specialized than frameworks
• Framework is executable software, design pattern represent
knowledge about software
• Frameworks are the physical realization of one or more software
pattern solutions, pattern are instructions for how to implement
those solutions

Component 22
Summary

Design
Patterns Tools
Theories &
Methods

Project
management

Produces

SW Reuse Good Software

Component 23