CS 501: Software Engineering
Lecture 17
Object Oriented Design 3
1
CS 501 Spring 2005
Administration
Second presentation and report next week
Final milestone: four weeks from handover
-- design complete, implementation begun
-- schedule for testing and revisions
-- plan for handover to client
Sign up for meeting times
Quiz 3
During class on Thursday
Teaching Assistant
Lin Guo away until April 17
2
CS 501 Spring 2005
Design Patterns
Design patterns:
E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design
Patterns: Elements of Reusable Object-Oriented Software.
Addison-Wesley, 1994
3
CS 501 Spring 2005
Sources
The following discussion of design patterns is based on
Gamma, et al., 1994, and Bruegge and Dutoit, 2004.
4
CS 501 Spring 2005
Design Pattern
Design patterns are template designs that can be used in a
variety of systems. They are particularly appropriate in
situations where classes are likely to be reused in a system that
evolves over time.
• Name. [Some of the names used by Gamma, et al. are
becoming standard software terminology.]
• Problem description. Describes when the pattern might be
used, often in terms of modifiability and extensibility.
• Solution. Expressed in terms of classes and interfaces.
• Consequences. Trade-offs and alternatives.
5
CS 501 Spring 2005
Design for Reuse: Inheritance and
Abstract Classes
Classes can be defined in terms of other classes using
inheritance. The generalization class is called the superclass
and the specialization is called the subclass.
If the inheritance relationship serves only to model shared
attributes and operations, i.e., the generalization is not intended to
be implemented, the class is called an abstract class
6
CS 501 Spring 2005
Design for Reuse: Implementation and
Specification Inheritance
Implementation Inheritance
Developers reuse code quickly by subclassing an existing class
and refining its behavior. Is not good for reuse.
Specification Inheritance
The classification of concepts into type hierarchies, so that an
object from a specified class can be replaced by an object from
one of its subclasses.
7
CS 501 Spring 2005
Design for Reuse: Specification
Inheritance
Liskov Substitution Principle (strict inheritance)
If an object of type S can be substituted in all the places where an
object of type T is expected, then S is a subtype of T.
Interpretation
The Liskov Substitution Principle means that if all classes are
subtypes of their superclasses, all inheritance relationships are
specification inheritance relationships. New subclasses of T can
be added without modifying the methods of T. This leads to an
extensible system.
8
CS 501 Spring 2005
Design for Reuse: Delegation
Delegation
A class is said to delegate to another class if it implements an
operation by resending a message to another class.
Delegation is an alternative to implementation inheritance
that should be used when reuse is anticipated.
9
CS 501 Spring 2005
Adapter:
Wrapping Around Legacy Code
Problem description:
Convert the user interface of a legacy class into a different
interface expected by the client, so that the client and the
legacy class can work together without changes.
This problem often occurs during a transitional period, when
the long-term plan is to phase out the legacy system.
Example:
How do you use a web browser to access an existing
information retrieval system that was designed for a different
client?
10
CS 501 Spring 2005
Adapter Design Pattern
NewClient
dependency
LegacyClass
NewClass
existingRequest()
request()
OldClient
11
CS 501 Spring 2005
Adapter Design Pattern:
Solution Class Diagram
Client
abstract class
ClientInterface
LegacyClass
request()
existingRequest()
Adapter
inheritance
12
delegation
request()
CS 501 Spring 2005
Adapter Design Pattern:
Consequences
The following consequences apply whenever the Adapter
design pattern in used.
• Client and LegacyClass work together without
modification of either.
• Adapter works with LegacyClass and all of its
subclasses.
• A new Adapter needs to be written if Client is replaced
by a subclass.
13
CS 501 Spring 2005
Bridge:
Allowing for Alternate Implementations
Name: Bridge design pattern
Problem description:
Decouple an interface from an implementation so that a different
implementation can be substituted, possibly at runtime (e.g.,
testing different implementations of the same interface).
14
CS 501 Spring 2005
Bridge:
Class Diagram
Client
alternative
implementations
ConcreteImplementorA
ConcreteImplementorB
15
CS 501 Spring 2005
Bridge:
Allowing for Alternate Implementations
Solution:
The Abstraction class defines the interface visible to the client.
Implementor is an abstract class that defines the lower-level
methods available to Abstraction. An Abstraction instance
maintains a reference to its corresponding Implementor instance.
Abstraction and Implementor can be refined independently.
16
CS 501 Spring 2005
Bridge:
Class Diagram
Client
Abstraction
whole/part
association
Implementor
ConcreteImplementorA
ConcreteImplementorB
17
CS 501 Spring 2005
Bridge:
Class Diagram
Client
Abstraction
Implementor
RefinedAbstraction
ConcreteImplementorA
new abstraction
18
ConcreteImplementorB
CS 501 Spring 2005
Bridge:
Consequences
Consequences:
Client is shielded from abstract and concrete implementations
Interfaces and implementations may be tested separately
19
CS 501 Spring 2005
Strategy:
Encapsulating Algorithms
Name: Strategy design pattern
Problem description:
Decouple a policy-deciding class from a set of mechanisms, so
that different mechanisms can be changed transparently.
Example:
A mobile computer can be used with a wireless network, or
connected to an Ethernet, with dynamic switching between
networks based on location and network costs.
20
CS 501 Spring 2005
Strategy:
Encapsulating Algorithms
Solution:
A Client accesses services provided by a Context.
The Context services are realized using one of several
mechanisms, as decided by a Policy object.
The abstract class Strategy describes the interface that is common
to all mechanisms that Context can use. Policy class creates a
ConcreteStrategy object and configures Context to use it.
21
CS 501 Spring 2005
Strategy Example:
Class Diagram for Mobile Computer
Application
LocationManager
NetworkInterface
NetworkConnection
send()
setNetworkInterface()
Note the
similarities to
Bridge pattern
22
Ethernet
open()
close()
send()
open()
close()
send()
WirelessNet
open()
close()
send()
CS 501 Spring 2005
Strategy:
Class Diagram
Client
Policy
Context
Strategy
contextInterface()
ConcreteStrategy1
23
algorithmInterface()
ConcreteStrategy2
CS 501 Spring 2005
Strategy:
Consequences
Consequences:
ConcreteStrategies can be substituted transparently
from Context.
Policy decides which Strategy is best, given the current
circumstances.
New policy algorithms can be added without modifying
Context or Client.
24
CS 501 Spring 2005
Abstract Factory:
Encapsulating Platforms
Name: Abstract Factory design pattern
Problem description:
Shield the client from different platforms that provide different
implementations of the same set of concepts
Example:
A browser must have versions that implement the same set of
concepts for several windowing systems, e.g., scroll bars, buttons,
highlighting, etc.
25
CS 501 Spring 2005
Abstract Factory:
Encapsulating Platforms
Solution:
A platform (e.g., the application for a specific windowing system)
is represented as a set of AbstractProducts, each representing a
concept (e.g., button). An AbstractFactory class declares the
operations for creating each individual product.
A specific platform is then realized by a ConcreteFactory and a set
of ConcreteProducts.
26
CS 501 Spring 2005
Abstract Factory:
Class Diagram
Client
AbstractFactory
createProductA
createProductB
AbstractProductA
ProductA
27
Classes for
ProductB are not
shown in this
diagram.
There could be
ConcreteFactory1 several
createProductA ConcreteFactory
createProductB classes, each a
subclass of
AbstractFactory,
CS 501 Spring 2005
Abstract Factory:
Consequences
Consequences:
Client is shielded from concrete products classes
Substituting families at runtime is possible
Adding new products is difficult since new realizations must
be created for each factory
28
CS 501 Spring 2005
Command:
Encapsulating Control Flow
Name: Command design pattern
Problem description:
Encapsulates requests so that they can be executed, undone, or
queued independently of the request.
Solution:
A Command abstract class declares the interface supported by all
ConcreteCommands. ConcreteCommands encapsulate a service
to be applied to a Receiver. The Client creates
ConcreteCommands and binds them to specific Receivers. The
Invoker actually executes a command.
29
CS 501 Spring 2005
Command:
Class Diagram
Invoker
invokes
Command
execute()
ConcreteCommand1
<<binds>>
execute()
Receiver
ConcreteCommand2
execute()
30
CS 501 Spring 2005
Command:
Class Diagram for Match
Match
invokes
Move
play()
replay()
Game1Move
<<binds>>
GameBoard
play()
replay()
Game1Move
play()
replay()
31
CS 501 Spring 2005
Command:
Consequences
Consequences:
The object of the command (Receiver) and the algorithm of
the command (ConcreteCommand) are decoupled.
Invoker is shielded from specific commands.
ConcreteCommands are objects. They can be created and
stored.
New ConcreteCommands can be added without changing
existing code.
32
CS 501 Spring 2005
Composite:
Representing Recursive Hierarchies
Name: Composite design pattern
Problem description:
Represents a hierarchy of variable width and depth, so that the
leaves and composites can be treated uniformly through a
common interface.
Solution:
The Component interface specifies the services that are shared
between Leaf and Composite. A Composite has an aggregation
association with Components and implements each service by
iterating over each contained Component. The Leaf services do
the actual work.
33
CS 501 Spring 2005
Composite:
Class Diagram
Client
Component
*
Leaf
34
Composite
leaves
CS 501 Spring 2005
Composite:
Consequences
Consequences:
Client uses the same code for dealing with Leaves or
Composites.
Leaf-specific behavior can be changed without changing the
hierarchy.
New classes of Leaves can be added without changing the
hierarchy.
35
CS 501 Spring 2005
Facade:
Encapsulating Subsystems
Name: Facade design pattern
Problem description:
Reduce coupling between a set of related classes and the rest of
the system.
Solution:
A single Facade class implements a high-level interface for a
subsystem by invoking the methods of the lower-level classes.
36
Example. A Compiler is composed of several classes:
LexicalAnalyzer, Parser, CodeGenerator, etc. A caller, invokes
only the Compiler (Facade) class, which invokes the contained
classes.
CS 501 Spring 2005
Facade:
Class Diagram
Facade
Facade
service()
37
Class1
Class2
Class3
service1()
service2()
service3()
CS 501 Spring 2005
Facade:
Consequences
Consequences:
Shields a client from the low-level classes of a subsystem.
Simplifies the use of a subsystem by providing higher-level
methods.
Enables lower-level classes to be restructured without
changes to clients.
Note. The repeated use of Facade patterns yields a layered
system.
38
CS 501 Spring 2005
Observer:
Encapsulating Control Flow
Name: Observer design pattern
Problem description:
Maintains consistency across state of one Subject and many Observers.
Solution:
A Subject has a primary function to maintain some state (e.g., a data
structure). One or more Observers use this state, which introduces
redundancy between the states of Subject and Observer.
Observer invokes the subscribe() method to synchronize the state.
Whenever the state changes, Subject invokes its notify() method to
iteratively invoke each Observer.update() method.
39
CS 501 Spring 2005
Observer:
Class Diagram
subscribers
Subject
subscribe()
unsubscribe()
notify()
ConcreteSubject
state
getstate()
setstate()
40
1
Observer
*
update()
ConcreteObserver
observeState
update()
CS 501 Spring 2005
Observer:
Consequences
Consequences:
Decouples Subject, which maintains state, from Observers,
who make use of the state.
Can result in many spurious broadcasts when the state of
Subject changes.
41
CS 501 Spring 2005
Proxy:
Encapsulating Expensive Objects
Name: Proxy design pattern
Problem description:
Improve performance or security of a system by delaying
expensive computations, using memory only when needed, or
checking access before loading an object into memory.
Solution:
The ProxyObject class acts on behalf of a RealObject class. Both
implement the same interface. ProxyObject stores a subset of the
attributes of RealObject. ProxyObject handles certain requests,
whereas others are delegated to RealObject. After delegation, the
RealObject is created and loaded into memory.
42
CS 501 Spring 2005
Proxy:
Class Diagram
Client
Object
filename
op1()
op2()
ProxyObject
filename
op1()
op2()
43
1
0..1
RealObject
data:byte[]
op1()
op2()
CS 501 Spring 2005
Proxy:
Consequences
Consequences:
Adds a level of indirection between Client and RealObject.
The Client is shielded from any optimization for creating
RealObjects.
44
CS 501 Spring 2005