Design PatternsIntroduction
“Patterns are discovered, not invented”Richard Helm
What’s a pattern?
A pattern is a named abstraction from a concrete form that represents a recurring solution to a particular problem.
Categories of Patterns Design patterns vary in granularity and
level of abstraction. By categorizing patterns, it becomes
easier to recognize and learn them patterns can be categorized by purpose
or scope purpose reflects what the pattern does scope specifies if the pattern applies to
classes or objects
purpose
reflects what the pattern does Creational -- facilitate object creation Structural -- deal with the composition
of classes or objects Behavioral -- deal with the way
objects interact and distribute responsibility
scope
whether the pattern applies to classes or objects
class patterns: deal with relationships between classes or
subclasses established through inheritance these relationships are fixed at compile time
objects patterns: deal with object relationships that can be changed at runtime
other ways to organize patterns
some patterns are frequently used with other patterns, for example composite is often used with visitor and/or iterator
some patterns are alternatives: Prototype is usually an alternative for Abstract Factory
Some patterns are very similar in structure, such as Composite and Decorator
How do Design Patterns Solve Design Problems?
The meaning of OO is well-known The hard part is decomposing the
system into objects to exploit: encapsulation flexibility, extensibility ease of modification performance evolution reusability
Finding objects
Many objects in the design come from the analysis model
But OO designs often end up with classes that have no counterpart in the real world
Design Patterns help the modeler to identify less obvious abstractions and the objects that can capture them.
Inheritance
Inheritance is a mechanism for reuse you can define a new kind of object in
terms of the old one you get new implementations almost
for free, inheriting most of what you need from an existing class
This is only half the story!
Program to an interface,not an implementation
Inheritance permits defining a family of objects with identical interfaces
polymorphism depends on this! all derived classes share the base class
interface Subclasses add or override 0perations, rather
than hiding operations All subclasses then respond to requests in the
interface of the abstract class
Inheritance properly used clients are unaware of types of objects: heuristic
5.12 - “explicit case analysis on the type of an object is usually an error. The designer should use polymorphism”. Riel
clients only know about the abstract classes defining the interface. heuristic 5.7: “All base classes should be abstract”. Riel
This reduces implementation dependencies program to an interface, not an implementation creational patterns help ensure this rule!
Two techniques for reuse
inheritance: white box object composition: black box
advantage of inheritance for reuse
defined statically supported directly by the language:
straightforward to use easier to modify implementation
being reused
disadvantage of inheritance can’t change inherited implementation at run-
time parent classes often define part of their
subclass’s physical representation because inheritance exposes the parent
implementation it’s said to “break encapsulation” (GOF p.19, Sny86)
change in parent => change in subclass What if inherited attribute is inappropriate?
object composition:black box reuse
objects are accessed solely through their interfaces: no break of encapsulation
any object can be replaced by another at runtime: as long as they are the same type
favor object composition over class inheritance. GOF p. 20
but inheritance & composition work together!
Delegation
“a way of making composition as powerful for reuse as inheritance”: GOF, p. 20 [JZ91] Ralph Johnson and Jonathan Zweig,
Delegation in C++, JOOP, f(11):22-35, Nov. 91
[Lie86] Henry Lieberman. Using prototypical objects to implement shared behavior in OO systems. OOPSLA, pp 214-223, Nov. ‘86
delegation: reuse
In delegation, 2 objects handle a request
analogous to subclass deferring request to parent
in delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver!
delegating area() to rectangle
Window
area()
RectangleHas-a
area()
return rectangle->area()return width*height
widthheight
advantages of delegation
can change behaviors at run-time window can become square at run-
time by replacing Rectangle with Square, (assuming Rectangle & Square are same type!)
There are run-time costs. delegation in patterns: State,
Strategy, Visitor, Mediator, Bridge
delegating area() to square
Window
area()
Square
Has-a area()
return square->area()return side*side
side
Patterns make design resistant to re-designRobustness to Change
Algorithmic dependencies: Template Method, Visitor, Iterator, Builder, Strategy.
Creating an object by specifying a class explicitly: Abstract Factory, Factory Method, Prototype
Dependence on specific operations: Command, Chain of Responsibility
Dependence on object representation or implementation: Abstract Factory, Bridge, Proxy
Tight coupling: Abstract Factory, Command, Facade, Mediator, Observer, Bridge
Patterns make design resistant to re-design
Extending functionality by subclassing: Command, Bridge, Composite, Decorator, Observer, Strategy
Inability to alter classes conveniently: Visitor, Adapter, Decorator
Design Confidence
Design Inexperience: “Is my design ok?”
Patterns engender confidence used twice & blame the GOF still room for creativity
Design Coverage
Large portion of design can be covered by patterns
Seductively simple to implement most explained in a few pages add no “extra-value” to end-user
You still have to write functionality: patterns don’t solve the problem
Design Understanding
Most people know the patterns If you’re looking at someone’s design & you
identify a pattern, you immediately understand much of the design
Common design vocabulary “Let’s use a Builder here”
Design language beyond language syntax Problem-oriented language program in rather than into the language
Common Problems
Getting the “right” pattern Taming over-enthusiasm
you “win” if you use the most patterns everything solved by the last pattern you
learned
How to select a pattern
know a basic catalog scan intent section study patterns of like purpose consider a cause of redesign
Top Related