Some questions to think about
Design Patterns
Are design patterns…
 Template?
 Reusable code?
 Rule of thumb?
 Guuidelines?
What IS a design pattern?
• A pattern is a named abstraction from a concrete
form that represents a recurring solution to a
particular problem.
 • Patterns = problem/solution pairs in context
 • Patterns facilitate reuse of successful software
architectures and design
 • Not code reuse
– Instead, solution/strategy reuse
– Sometimes, interface reuse
 • Best practices
 • “Patterns are discovered, not invented” - Richard
Helm

Are design patterns language
specific?

Most design patterns focus on OO
 Assume inheritance, polymorphism,
encapsulation, etc.
In procedural languages, might add OO
features as “patterns”
 Some languages provide or make it
easier to implement some patterns

Categories of Patterns
Design patterns vary in granularity and
level of abstraction.
 By categorizing patterns, it becomes
easier to recognize and learn them
 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

Design Patterns Organization
Design Patterns
Purpose
Creational
Structural
Behavioral
Scope
Objects
Classes
Other ways of organizing 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
Knowing your 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.

Interface vs 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 operations,
rather than hiding operations
All subclasses then respond to requests in
the interface of the abstract class
Reuse: Two techniques
• Inheritance: White box
 • Object Composition: Black box

Why inheritance for reuse?
Defined statically
 Supported directly by the language:
straightforward to use
 Easier to modify implementation being
reused

Disadvantages of inheritance for
reuse





Can’t change inherited implementation at
run-time
Parent classes often define part of their
subclasses physical representation
Because inheritance exposes the parent
implementation it’s said to “break
encapsulation”
Change in parent => Change in subclass
If inherited attribute is inappropriate?
Example
A duck not only
quacks, swims
and…is displayed
 Ducks can…Fly!!
 How to give duck
flying ability?
 Inheritance?

Flying duck through inheritance





How about Rubber
Ducks?
Don’t quack();
already overidden to
squeak
Don’t fly at all;
overide to do
nothing?
What about
DecoyDucks
– They don’t quack
or fly
Slightly better solution
Alternate solution: Interface for
Ducks
Compostion > Inheritance?
Objects are accessed solely through their
interfaces: no break of encapsulation
 Any object can be replaced by another a
runtime: as long as they are the same type
 Favor object composition over class
inheritance.
 But inheritance & composition work
together

Delegation

“a way of making composition as
powerful for reuse as inheritance”:
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 Triangle
Delegation advantages
Can change behaviors at run-time
 • Window can become circular at runtime by replacing Rectangle with Circle,
 (assuming Rectangle & Circle are same
type!)
 There are run-time costs.
 Delegation in patterns: State, Strategy,
Visitor, Mediator, Bridge

Redesigned Duck
Encapsulated Quack Behavior
Encapsulated Fly behavior
Patterns Make Design Resistant
to Re-Design
Robustness 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 rep or implementation: Abstract
Factory,
Bridge, Proxy
Tight coupling: Abstract Factory, Command, Facade,
Mediator, Observer, Bridge
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

Guidelines to prevent UnderEngineering
 Time constraints often force production of
poorly designed code
 Leads to unmaintainable code
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 related to
design patterns
Getting the “right” pattern
 Taming over-enthusiasm

 you “win” if you use the most patterns
 everything solved by the last pattern you
learned

Over-Engineering
 More sophisticated or flexible than
necessary
Weaknesses of design patterns

Targets wrong problem
 Missing language features
Lacks formal foundations
 Does not provide reuse (like components)
 Leads to inefficient solutions
 Does not differ significantly from other
abstractions

 Model-View-Controller predates GoF patterns
How to choose a design pattern
Know a basic catalog
 Scan intent section
 Study patterns of like purpose
 Consider a cause of redesign
 Refactor toward or away from patterns
to avoid over/under design

 Much thanks to R.Stehwein!