"Design Patterns" in 2.5 Hours
First, A Word from our Sponsor
lecture #1 began here
Class Notes: http://www.cs.nmsu.edu/~jeffery/courses/579/patterns.html
Reading:
Design Patterns Background
Design Patterns were invented in homage to architectural patterns,
specifically the work of Christopher Alexander. Their initial introduction
for software design, in a book by Gamma, Helm, Johnson and Vlissides in 1995,
had an electrifying effect: suddenly it was no longer possible to talk about
software design without referring to as many of the patterns as possible.
A whole mini-industry and cult sprang up around the task of specifying as
many patterns as possible. Of course, most of those patterns are not
very useful.
The original design patterns book described in detail 23 reoccurring
patterns in software, divided into three main categories: creational,
structural, and behavioral. Each pattern is described exceedingly well in
prose and outlined in a UML class diagram, after which example
implementations are sketched in C++ or Smalltalk. Within all three
categories a great deal of similarity can be observed, such as the heavy
use of abstract classes; enough to suggest the existence of meta-patterns.
The design patterns fad has died down, but the concept of design patterns
has been thoroughly institutionalized by the software engineering community.
What is a Design Pattern?
Minimalist Definition
A quad-tuple consisting of:
a pattern name
a description of what problem it solves
a description of the solution
an assessment of consequences and implications of the pattern
Expanded Definition
Name and Classification
Intent
Also Known As
Motivation
Applicability
Structure (e.g. UML)
Participants
Collaborations
Consequences
Implementation
Sample Code
Known Uses
Related Patterns
How Design Patterns Solve Design Problems
finding objects - if the pattern says you need one, you need one
determining granularity - several patterns address granularity explicitly
specifying interfaces - patterns describe part or all of the
public interfaces of the classes in them
specifying implementations - patterns may include known-efficient
code samples
code reuse - "design reuse facilitates code reuse"
How to Select a Design Pattern
GoF suggest several ways, such as
look for which design problem above affects you, then look for
design patterns that pertain to it
scan all the patterns' Intent sections
study how patterns interrelate
study patterns of similar purpose - to tell when to use which
I would just add that, first you familiarize yourself with a bunch
of design patterns, and then when doing design you recognize which
pattern to use via deja vu.
How to Use Design Patterns
Buy the GoF book, read the pattern in detail
Look at the sample code to get a concrete feel for it
Apply (translate) the pattern Structure section to your application classes Adapt the sample code when it is appropriate to do so; otherwise write your own
Design Patterns versus Pattern Languages
Students of Christopher Alexander were quick to note that the design
patterns book is mostly just a catalog of buzzwords and misses the
point. Design patterns should be more about the rules for
connecting patterns than about the individual patterns themselves,
which we mostly already know or could invent when needed.
I started getting into this with a mathematician colleague in
San Antonio, but then moved to Las Vegas and then Las Cruces,
and have been too busy to pursue this to its appropriate conclusion.
Some Cynical Observations About Design Patterns
Of course these were not new inventions, they were a catalog of
tried and true methods. That is OK.
Design Patterns proponents are trying to create a common vocabulary of
buzzwords, to reduce the cost of communication and increase the level
of understanding when software engineers are talking with one another.
Name That Design Pattern
If we do well enough on this quiz, we have a common vocabulary, and
have either already learned design patterns, or don't actually need them.
Provide an interface for creating objects without specifying their
concrete classes.
Separate the construction of a complex object from its representation.
Let subclasses decide which class to instantiate for a specified
object-creation interface.
Specify objects to create using a prototypical instance; create objects
by copying.
Ensure a class has only one instance, and provide a global point of access.
Convert the interface of a class into another interface, expected by clients.
Decouple abstraction from implementation, so the two can vary independently.
Compose objects into tree structures to represent part-whole hierarchies.
Treat individuals and composites uniformly.
Attach additional responsibilities to an object dynamically.
Provide a single unified interface to a set of subsystem interfaces.
Use sharing to support large numbers of fine-grained objects efficiently.
Provide a surrogate or placeholder for another object.
Give more than one object a chance to handle an incoming message.
Pass the request along the chain until an object handles it.
Encapsulate a request as an object.
Interpret sentences in a language by defining and operating on an
internal data structure representation of that language.
Provide a way to access the elements of an aggregate object sequentially.
Define an object that encapsulates how a set of objects interact.
Capture and externalize an object's internal state so that the object
can be restored to this state later.
Create a mechanism such that when one object changes its state, all
its dependent observers are notified and updated.
Allow an object to alter its behavior when its internal state changes,
appearing to have changed its class.
Define a set of encapsulated, interchangeable, algorithms; allow algorithms
to vary independently of their clients.
Define the skeleton of an algorithm, deferring some steps to subclasses.
Represent an operation on elements of an object structure; enable new
operations without changing the element classes.
lecture #2 began here
Homework Assignment 5 is up, let's look at
it
Emphasis on patterns is analogous to emphasis on associations instead of classes
Patterns are about systems, not just individual components
Patterns can form "microarchitectures"
Patterns can be applied to other areas besides design (process patterns,
user interface patterns, teaching patterns, project organization
patterns, software process patterns...)
Patterns can be "interdisciplinary" among different software areas.
Patterns thrive on capturing and articulating points of complexity
(no complexity => no need for patterns). OOP needs patterns
worse than traditional structured programming because OOP tends
to be more complex than structured programming (e.g. dynamic
data-driven
relationships instead of static code-control-flow relationships).
Patterns' immediate ancestor were "programming idioms"
- Idioms capture a solution to a problem in a context (= pattern)
- Idioms capture (language-specific) interactions between objects
- Design patterns capture language-independent interactions
Patterns are about people, not houses, or software. The human
side is usually about either utility, or aesthetics. Software
designs tend to capture API's and data structures but miss nuances
of relationships; software process distances itself from unreliable
human beings.
Human Software Pattern Example:
Simply Understood Code
This is not a software paper, nor an architecture paper. He is a
mathematician and interested in patterns in the pure abstract.
Pattern language == "connective rules" for patterns.
Criticism of GOF Design Patterns catalogue-feel and lack of
connective rules applies equally well to Alexander's architecture
patterns books.
Examples of pattern connections:
- A pattern contains or generalizes a smaller pattern
- Two patterns are complementary and need each other for completeness
- Two patterns solve problems that overlap and coexist on the same level
- Two patterns solve the same problem in alternative (both valid) ways
- Distinct patterns share a similar structure, implying a meta-pattern
Design is tremendously hard work, and patterns do not provide an
algorithm or make the hard work go away.
Alexander sorts his patterns in order of decreasing scale, since
decisions on the largest scale have to be made first; does GOF do this?
Small to large (Salingaros' order) would facilitate bottom-up
understanding of patterns; does GOF do this?
Patterns may operate at different levels; many interesting patterns
connect different levels.
Let's look at some of
Salingaros' diagrams
The Patterns
Abstract Factory
Provide an interface for creating objects without specifying their
concrete classes.
Builder
Separate the construction of a complex object from its representation.
Factory Method
Let subclasses decide which class to instantiate for a specified
object-creation interface.
Prototype
Specify objects to create using a prototypical instance; create objects
by copying.
Singleton
Ensure a class has only one instance, and provide a global point of access.
Adapter
Convert the interface of a class into another interface, expected by clients.
Bridge
Decouple abstraction from implementation, so the two can vary independently.
Composite
Compose objects into tree structures to represent part-whole hierarchies.
Treat individuals and composites uniformly.
Decorator
Attach additional responsibilities to an object dynamically.
Facade
Provide a single unified interface to a set of subsystem interfaces.
Flyweight
Use sharing to support large numbers of fine-grained objects efficiently.
Proxy
Provide a surrogate or placeholder for another object.
Chain of Responsibility
Give more than one object a chance to handle an incoming message.
Pass the request along the chain until an object handles it.
Command
Encapsulate a request as an object.
Interpreter
Interpret sentences in a language by defining and operating on an
internal data structure representation of that language.
Iterator
Provide a way to access the elements of an aggregate object sequentially.
Mediator
Define an object that encapsulates how a set of objects interact.
Memento
Capture and externalize an object's internal state so that the object
can be restored to this state later.
Observer
Create a mechanism such that when one object changes its state, all
its dependent observers are notified and updated.
State
Allow an object to alter its behavior when its internal state changes,
appearing to have changed its class.
Strategy
Define a set of encapsulated, interchangeable, algorithms; allow algorithms
to vary independently of their clients.
Template Method
Define the skeleton of an algorithm, deferring some steps to subclasses.
Visitor
Represent an operation on elements of an object structure; enable new
operations without changing the element classes.
