1. Design Patterns

2. Motivation/Background (1)
Developing software is hard
Developing reusable software is even harder
Why not leverage proven solutions to common problems?
Two ways to do this:
Design Patterns
Support reuse of class-level design
Capture static and dynamic structures and collaborations of successful solutions
Frameworks
Support reuse of detailed design and code
Integrated set of components that provide partial solutions to problems

3. Motivation/Background (2)
How do you become a software design master?
Learn the foundations
Algorithms, data structures, programming languages
Learn the principles of good design
Abstraction, encapsulation, and modularity
Study the designs of masters
Understand, memorize, mimic
Practice
Hands-on experience, multiple situations

4. Intro to Design Patterns
Represent sound solutions to common problems that arise with particular contexts
Particularly useful at resolving nonfunctional forces
Ease of modification
Ease of reuse
Ease of extension
A good design is revealed
when you attempt to change it

5. An Example: The Observer Design Pattern (1)
Sample application: stock quote service
Intent: define one-to-many dependency between objects so that when one object changes state, all its dependent objects are notified

6. An Example: The Observer Design Pattern (2)
Key Forces:
There may be many observers
Each observer may react differently to same notification
The observable should be decoupled from the observers to allow them to change independently
Observers should be able to query observable for required information

7. An Example: The Observer Design Pattern (3)
Structure of the Design Pattern:
Not really
necessary

8. An Example: The Observer Design Pattern (4)
Collaboration of the Design Pattern:
Not
needed

9. Canonical Design Pattern Description
Name
Intent
Forces
Non-Software Example
Abstract Description
Implementation Issues
Consequences
Java API Usage
Responsibility-Driven Post-Mortem
Example

10. Frameworks vs. Patterns (1)
Important to understand the relationship between these two ways to reuse designs
Frameworks (1)
Semi-complete applications
Can be tailored to specific applications
Inheritance
Template Instantiation
Callbacks
Frameworks provide domain-specific functionality
Ex: Backtracking framework

11. Frameworks vs. Patterns (2)
Frameworks exhibit inversion of control
Framework acts on domain classes
Framework pulls domain objects into process
Typically through hooks or callbacks
Benefits of Frameworks
Enable direct reuse of code
Enable reuse of overall design
Drawbacks of Frameworks
High initial learning curve
Many classes, interfaces, levels of abstraction
Flow of control is non-intuitive
Pull versus push model
Hard to see how domain code fits

12. Frameworks vs. Patterns (3)
Several different types of software patterns
Architectural
Design
Idioms
Architectural Patterns
Expose fundamental structural organization of system or subsystem
Provide decomposition into subsystems
Provide “big picture” of system
High-level Abstraction
Example: Blackboard Architecture

13. Frameworks vs. Patterns (4)
Design Patterns
Provide scheme for refining components
Freeze commonly-reoccurring structure
Middle-level Abstraction
Example: Observer/Observable
Notice how this could be used to implement a blackboard architecture
Idioms
Describe how to implement a particular aspect of a component in some language
Low-level Abstraction
Example: Reference Counts

14. Structure of Design Patterns (1)
Divided by purpose and scope (1)
Scope
Does it apply to classes or objects?
Class Patterns deal with relationships between classes
Static – compile-time relationships
Frequently involve inheritance
Not the typical design pattern
Object Patterns deal with relationships between objects
Dynamic – change at run-time
Frequently involve aggregation/delegation

15. Structure of Design Patterns (2)
Divided by purpose and scope (2)
Purpose
What the pattern does
Three categories
Structural Patterns
Creational Patterns
Behavioral Patterns
Deal with decoupling interface and implementation
Set the system up for modification
Examples:
Adapter – translate one interface to another
Composite – recursive aggregation

16. Structure of Design Patterns (3)
Divided by purpose and scope (3)
Creational Patterns
Initialization and configuration
Examples
Singleton – controlled instance count
Factory Method – use inheritance to create instances of abstract classes
Behavioral Patterns
Dynamic interactions among objects/classes
Examples:
Iterator – give sequential access to collection
Template Method – separate variant and invariant aspects of process

17. Structure of Design Patterns (4)
What makes a pattern a “pattern”? (1)
Describe a problem
A problem that arises frequently
Explains forces at work
Ex: Aspects that must be changed frequently
Present a solution
Proven solution to the problem
Must indicate how it balances the active forces
Must define both static and dynamic aspects of solution

18. Structure of Design Patterns (5)
What makes a pattern a “pattern”? (2)
Have a context
Must indicate when/where the solution can be used
Describes the situation in which the problem arises
Recur
Must be relevant to more than one situation
Teach
Must provide sufficient understanding to allow it to be tailored
Name

19. Key Principles of Design Patterns
Separate interface from implementation
Program to the interface, not the implementation
Separate variant from invariant aspects
Define what is likely or desirable to change
Build in flexibility for variant aspects
Prefer aggregation/delegation/composition over inheritance
Use aggregation to extend existing code
Creates “black box” reuse
Inheritance is for defining abstract hierarchies
Open/Closed Principle
Open to extension, closed to modification
Easy to extend and does not require modification to do so

20. Key Benefits of Design Patterns
Large-scale reuse of class architecture
Above the single class level
Capture expert knowledge/tradeoffs
Improve developer communication
Own vocabulary
Encourage documentation/review

21. Design Pattern Books
“Design Patterns”, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Excellent reference
Not generally considered a good textbook
Examples in C++
“Head First Design Patterns” by Eric Freeman and Elisabeth Freeman
Better as a textbook
Weaker as a reference
Examples in Java
Others…

22. Key Drawbacks of Design Patterns
No direct code reuse
Language-independent
Must be recoded each time
Deceptively simple
Leads to misuse
Overload
Can be too many patterns to find what you want
Validated only through experience/discussion
No formal testing of design patterns
Refactoring development process takes time
Several attempts to understand how/when to use

23. Anti-Patterns Introduced by William Brown Tells what to avoid
Classic book by same name
Another good book - “Bitter Java”, by Bruce Tate
Tells what to avoid
Key is that it looks great but will fail
An anti-pattern is
A pattern that tells:
how to go from a problem to a bad solution
how to go from a bad solution to a good solution
Simple Examples:
Using primitive arrays rather than array objects
Cut-and-paste programming – “one rule one place”