CS 4448 - Spring 1998
Object-Oriented Programming and Design
Lecture 14.2
Design Patterns
Design Patterns Overview
What is a design pattern?
- A general expression of a solution to common problems within a context.
- "... a named nugget of insight that conveys the essence of a proven solution to
a recurring problem within a certain context amidst competing concerns"
(from Brad Appleton's
pattern overview)
- Each named pattern forms a vocabulary - i.e., a pattern language.
- Pattern languages can lead to:
- Idea reuse
- A media for communication and documentation
- "This is a composite pattern"
- "This is a singleton pattern"
- Building blocks for expressing larger constructs - i.e., frameworks.
Becoming a Master Chess Player
- Learn rules and physical requirements
- board configuration, pieces, legal moves, etc.
- Learn principles
- Relative value of pieces, value of board positions, etc.
- To become a master you must study the games of other masters.
- These games contain patterns that are reused and must be understood and reused.
- Famous opening games
- Famous end games
- There are 1000's of these patterns
Example inspired by Douglas C. Schmidt, schmidt@cs.wustl.edu
Becoming a Master Software Designer
- Learn rules and physical requirements
- language syntax, algorithms, data structures
- Learn principles
- Modularization, recursion, object-oriented programming
- To become a master you must study the programs of other masters.
- These programs contain patterns that are reused and must be understood and reused.
- There are 1000's of these patterns
Example inspired by Douglas C. Schmidt, schmidt@cs.wustl.edu
Meta-Patterns
- Encapsulation (chunking?)
- Type based (e.g., class)
- Object based (i.e., object method invocation)
- Delegation
- Intra-object (i.e., self method call, virtual methods)
- Inter-object (i.e., object method invocation)
Meta-Patterns Examples
Abstract factory | Inter-object delegation
|
Factory method | Intra-object delegation
|
Prototype | ????
|
Singleton | ????
|
Adapter | Inter-object delegation
|
Composite | Object based encapsulation
|
Facade | Type based encapsulation
|
Proxy | Inter-object delegation
|
Chain of responsibilty | Inter-object delegation
|
Command | Type based encapsulation
|
Iterator | Type based encapsulation
|
Visitor | Type based encapsulation
|
Mediator | ?? Type and object encapsulation
|
Strategy | Inter-object delegation
|
Template method | Intra-object delegation
|
Abstract Factory
Intent
Provide an interface for creating families of related or dependent
objects without specifying their conrete classes
Applicability
- A system should be independent of how its products are created, composed
and represented
- A system should be configured with one of multiple families of products
- A family of related product objects is designed to be used together, and you need to enforce this constraint.
- You want to provide a class library of products and you want to reveal
just their interfaces.
Consequences
- It isolates concrete classes... encapsulation.
- It makes exchanging product families easy.
- Promotes consitency among products.
- Adding new product families is difficult, but ... see 2 above.
Implementation issues
- Factories as singletons. When not??
- Uniformity of access
- Creating the products
- Prototype pattern
- Concrete/abstract product mismatch. Proxy?? Adapter??
- How do you figure out what factory to use, e.g., Factory factory
- Compile time
- Determined (fixed) at runtime based on environment, e.g., ET++
- Dynamic loading
- Data driven dynamic dynamic loading
Related pattern
An abstract factory can also be used as a facade pattern.
ET++ example
if (gWindowSystem == 0 && Env::Defined("GLX"))
gWindowSystem= Load("glxserver", "GLXWinSystem");
if (gWindowSystem == 0 && Env::Defined("DISPLAY"))
gWindowSystem= Load("xwindow", "XWinSystem");
if (gWindowSystem == 0 && Env::Defined("WINDOW_PARENT"))
gWindowSystem= Load("sun", "SunWindowSystem");
if (gWindowSystem == 0) {
fprintf(stderr, "can't initialize window system\n");
gSystem->Exit(-1);
}
Pattern Format
- Pattern name and classification
- Intent
A short synopsis of what this pattern does.
- AKA
What else is this pattern known by?
- Motivation
A concrete example of the problem this pattern addresses
- Applicability
When should you use this pattern?
- Structure
Class structure
- Participants
A description of the classes and their responsibilities.
- Collaborations
What actualls happens at run time? e.g., object collaboration diagram
- Consequences
What is the concrete benefits and constraints using this pattern provides.
- Implementation
When implementing a pattern waht are some of the actual
issues that have to be addressed.
- Sample Code
- Known uses
- Related patterns
Adam Jonathan Griff,
computer@griffmonster.com
Copyright © University of Colorado. All rights reserved.
Revised: April 28, 1998