Object-Oriented Software Engineering
Practical Software Development using UML and Java
Chapter 6,
Using Design Patterns
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 2
6.1 Introduction to Patterns
The recurring aspects of designs are calleddesignpatterns.
? A pattern is the outline of a reusable solution to a general problem
encountered in a particular context
? Many of them have been systematically documented for all software
developers to use
? A good pattern should
— Be as general as possible
— Contain a solution that has been proven to effectively solve the
problemin the indicated context.
Studying patterns is an effective way to learn from the experience of
others
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 3
Pattern description
Context:
? The general situation in which the pattern applies
Problem:
— A short sentence or two raising the main difficulty.
Forces:
? The issues or concerns to consider when solving the problem
Solution:
? The recommended way to solve the problemin the given context.
— ‘to balance the forces’
Antipatterns:(Optional)
? Solutions that are inferior or do not work in this context.
Related patterns,(Optional)
? Patterns that are similar to this pattern.
References:
? Who developed or inspired the pattern.
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 4
6.2 The Abstraction-Occurrence Pattern
? Context:
— Often in a domain model you find a set of related objects
(occurrences).
— The members of such a set share common information
- but also differ from each other in important ways.
? Problem:
— What is the best way to represent such sets of occurrences in a
class diagram?
? Forces:
— You want to represent the members of each set of occurrences
without duplicatingthe common information
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 5
Abstraction-Occurrence
? Solution:
TVSeries
seriesName
producer
Episode
number
title
storySynopsis
*
?Occurrence??Abstraction? *
Title
name
author
LibraryItem
barCodeNumber
*
isbn
publicationDate
libOfCongress
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 6
Abstraction-Occurrence
Antipatterns:
n a m e
a u th o r
L i b r a r y It e m
b a rC o d e N u m b e r
i s b n
p u b l ic a t io n D a t e
l ib O fC o n g re s s
T i t l e
n a m e
a u th o r
L i b r a r y It e m
b a rC o d e N u m b e r
i s b n
p u b l ic a t io n D a t e
l ib O fC o n g re s s
n a m e
a u th o r
L i b r a r y I t e m
b a rC o d e N u m b e r
i s b n
p u b l ic a t io n D a t e
l ib O fC o n g re s s
G u l l iv e r s T r a v e l s M o b y D ic k
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 7
Abstraction-Occurrence
Square variant
ScheduledTrain
number
SpecificTrain
date
*
* *
ScheduledLeg SpecificLeg
actualDepTime
*
actualArrTime
scheduledDepTime
scheduledArrTime
Station
origin destination* *
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 8
6.3 The General Hierarchy Pattern
? Context:
— Objects in a hierarchy can have one or more objects above them
(superiors),
- and one or more objects below them (subordinates).
— Some objects cannot have any subordinates
? Problem:
— How do you represent a hierarchy of objects,in which some
objects cannot have subordinates?
? Forces:
— You want a flexible way of representing the hierarchy
- that prevents certain objects from having subordinates
— All the objects have many common properties and operations
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 9
General Hierarchy
? Solution,?subordinate?
*?Node?
?SuperiorNode??NonSuperiorNode?
* supervises
Manager
Employee
TechnicianSecretary
0..1
0..1
* contains
Directory
FileSystemItem
File
0..1
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 10
General Hierarchy
Antipattern:
RockRecordingBluesRecordingClassicalRecordingJazzRecordingMusicVideo
VideoRecoding AudioRecording
Recording
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 11
6.4 The Player-Role Pattern
? Context:
— A role is a particular set of properties associated
with an object in a particular context.
— An object may play different roles in different
contexts.
? Problem:
— How do you best model players and roles so that a
player can change roles or possess multiple roles?
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 12
Player-Role
? Forces,
— It is desirable to improve encapsulation by capturing
the information associated with each separate role in
a class.
— You want to avoid multiple inheritance,
— You cannot allow an instance to change class
? Solution,?Player?
?Role1? ?Role2?
?AbstractRole?
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 13
Player-Role
Example 1:
A n i m a l H a b i t a t R o l e
h a b i t a tt y p e O f F o o d
O m n i v o r eH e r b i v o r e L a n d A n i m a lA q u a t i c A n im a l
0., 2
C a r n i v o r e
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 14
Player-Role
Example 2:
L e v e l R o l e
a t t e n d a n ce
P a r t T im e S t u d e n tF u ll T i m e S t u d e n t U n d e r g r a d u a t e S t u d e n tG r a d u a t e S t u d e n t
l e v e l
S t u d e n tA t t e n d a n c e R o l e
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 15
Player-Role
Antipatterns:
? Merge all the properties and behaviours into a single
?Player?class and not have ?Role?classes at all.
? Create roles as subclasses of the ?Player?class.
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 16
6.5 The Singleton Pattern
? Context:
— It is very common to find classes for which only one
instance should exist (singleton)
? Problem,
— How do you ensure that it is never possible to create
more than one instance of a singleton class?
? Forces,
— The use of a public constructor cannot guarantee that
no more than one instance will be created.
— The singleton instance must also be accessible to all
classes that require it
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 17
Singleton
? Solution:
Company
theCompany
Company ?private?
getInstance
if (theCompany==null)
theCompany= new Company();
return theCompany;
?Singleton?
theInstance
getInstance
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 18
6.6 The Observer Pattern
? Context,
— When an association is created between two classes,
the code for the classes becomes inseparable,
— If you want to reuse one class,then you also have to
reuse the other.
? Problem,
— How do you reduce the interconnection between
classes,especially between classes that belong to
different modules or subsystems?
? Forces,
— You want to maximize the flexibility of the system
to the greatest extent possible
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 19
Observer
? Solution:
W e a t h e r V i e w e r
* *
Obs erv e r s ar e
no t i f ie d w hen a n ew
pre d ic t i on i s rea d y
F o r e c a s t e r
O b s e r v a b l e
獵 o n c r e t e O b s e r v a b l e 獵 o n c r e t e O b s e r v e r
玂 b s e r v a b l e
ad dOb s erv e r
no t i f y Obs erv e r s
玦 n ter f a ce
玂 b s e r v e r
up dat e
* *
玦 n ter f a ce
O b s e r v e r
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 20
Observer
Antipatterns:
? Connect an observer directly to an observable so that
they both have references to each other.
? Make the observers subclasses of the observable.
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 21
6.7 The Delegation Pattern
? Context,
— You are designing a method in a class
— You realize that another class has a method which
provides the required service
— Inheritance is not appropriate
- E.g,because the isa rule does not apply
? Problem,
— How can you most effectively make use of a method
that already exists in the other class?
? Forces,
— You want to minimize development cost by reusing
methods
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 22
Delegation
? Solution:
LinkedList
addFirst
addLast
addAfter
removeFirst
removeLast
delete
isEmpty
Stack
push
pop
isEmpty
?Delegate??Delegator?
delegatingMethod()
{
delegate.method();
} delegatingMethod method
push()
{
list.addFirst();
}
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 23
Delegation
Example,* * S p e c i f i c F l i g h tB o o k in g
f li gh tN u m be r() f li gh tN u m be r()
R e g u la r F li g h t
f li gh tN u m be r()
*
flightNumber()
return
specificFlight.flightNumber();
}
{
flightNumber()
return
regularFlight.flightNumber();
}
{
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 24
Delegation
Antipatterns
? Overuse generalization and inherit the method that is to
be reused
? Instead of creating a single method in the ?Delegator?
that does nothing other than call a method in the
?Delegate
— consider having many different methods in the
?Delegator? call the delegate’s method
? Access non-neighboring classes
return specificFlight.regularFlight.flightNumber();
return getRegularFlight().flightNumber();
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 25
6.8 The Adapter Pattern
? Context,
— You are building an inheritance hierarchy and want to
incorporate it into an existing class,
— The reused class is also often already part of its own inheritance
hierarchy.
? Problem:
— How to obtain the power of polymorphism when reusing a class
whose methods
- have the same function
- but not the same signature
as the other methods in the hierarchy?
? Forces:
— You do not have access to multiple inheritance or you do not
want to use it.
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 26
Adapter
? Solution:
?Adaptee?
adaptedMethod
?Superclass?
polymorphicMethod
?Adapter?
polymorphicMethod()
return
adaptee.adaptedMethod();
{
}
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 27
Adapter
Example:
TimsTorus
calcVolume
ThreeDShape
volume
Sphere Torus
volume()
return
adaptee.calcVolume();
{
}
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 28
6.9 The Fa?ade Pattern
? Context,
— Often,an application contains several complex packages,
— A programmer working with such packages has to manipulate
many different classes
? Problem,
— How do you simplify the view that programmers have of a
complex package?
? Forces:
— It is hard for a programmer to understand and use an entire
subsystem
— If several different application classes call methods of the
complex package,then any modifications made to the package
will necessitate a complete review of all these classes.
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 29
Fa?ade
? Solution:
玃 a c k a g e C l a s s 3
玃 a c k a g e C l a s s 2
玃 a c k a g e C l a s s 1
*
R e g u l a r F l i g h t
*
P e r s o n
A i r l i n e
f in dF l i gh t
m ak eB o ok in g
de le t e B oo k i ng
獸 a c a d e
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 30
6.10 The Immutable Pattern
? Context,
— An immutable object is an object that has a state that never
changes after creation
? Problem,
— How do you create a class whose instances are immutable?
? Forces,
— There must be no loopholes that would allow ‘illegal’
modification of an immutable object
? Solution:
— Ensure that the constructor of the immutable class is the only
place where the values of instance variables are set or modified.
— Instance methods which access properties must not have side
effects.
— If a method that would otherwise modify an instance variable is
required,then it has to return a new instance of the class.
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 31
6.11 The Read-only Interface Pattern
? Context,
— You sometimes want certain privileged classes to be able to
modify attributes of objects that are otherwise immutable
? Problem:
— How do you create a situation where some classes see a class as
read-onlywhereas others are able to make modifications?
? Forces,
— Restricting access by using the public,protected and
private keywords is not adequately selective,
— Making access publicmakes it public for both reading and
writing
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 32
Read-only Interface
? Solution:
?UnprivilegedClass?
* ?Mutator?
?Mutable?
attribute ?private?
getAttribute
setAttribute
?interface?
?ReadOnlyInterface?
getAttribute
*
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 33
Read-only Interface
Example:
Mutableperson
firstName
lastName
setFirstName
setLastName
getName
?interface?
Person
getName
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 34
Read-only Interface
Antipatterns:
? Make the read-only class a subclass of the ?Mutable? class
? Override all methods that modify properties
— such that they throw an exception
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 35
6.12 The Proxy Pattern
? Context:
— Often,it is time-consuming and complicated to create instances
of a class (heavyweight classes).
— There is a time delay and a complex mechanism involved in
creating the object in memory
? Problem,
— How to reduce the need to create instances of a heavyweight
class?
? Forces,
— We want all the objects in a domain model to be available for
programs to use when they execute a system’s various
responsibilities,
— It is also important for many objects to persist from run to run
of the same program
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 36
Proxy
? Solution:
?interface?
?ClassIF?
* *?Client? ?HeavyWeight??Proxy?
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 37
Proxy
Example:
?interface?
ListIF The list elements will be loaded into local
memory only when
needed.
ListProxy PersistentList
?interface?
Student
PersistentStudentStudentProxy
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 38
6.13 Detailed Example,The Observable
layer of OCSF
ObservableServerObservableClient
AbstractServerAbstractClient
Observable
ConnectionToClient
AdaptableServer
clientConnected
clientDisconnected
serverStarted
serverStopped
handleMessageFromClient
AdaptableClient
connectionEstablished
connectionClosed
handleMessageFromServer
*
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 39
The Observable layer of OCSF (continued)
O b s e r v a b l e S e r v e r
l is t en
s to pL i s t en in g
c l os e
s en dT oAl l C li en ts
i s L is te ni ng
ge tC l i en t C o nn e c t io ns
ge tN u m be rOf C l ie nt s
ge tPo rt
s et Port
c l i en t C o nn n ec t ed
c l i en t D i s c on ne c te d
s erv erSt art e d
s erv erSt op p ed
ha nd l eM e s s ag e F rom C l ie nt
O b s e r v a b l e C l ie n t
op en C o nn e c t io n
c l os eC o nn e c t io n
s en dT oSe rv er
i s C o nn e c t ed
ge tPo rt
s et Port
ge tH o s t
s et H os t
ge tI ne tAd dres s
ha nd l eM e s s ag e F rom Serv e r
c o nn e c t io nC l os ed
c o nn e c t io nEs ta bl is he d
O b s e r v a b l e
A d a p t a b l e S e r v e rA d a p t a b l e C li e n t
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 40
Using the observable layer
1,Create a class that implements the Observer interface.
2,Register it as an observer of the Observable:
public MessageHandler(Observable client)
{
client.addObserver(this);
...
}
3,Define the update method in the new class:
public void update(Observable obs,Object message)
{
if (message instanceOf SomeClass)
{
// process the message
}
}
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 41
6.14 Difficulties and Risks When Creating
Class Diagrams
? Patterns are not a panacea:
— Whenever you see an indication that a pattern should
be applied,you might be tempted to blindly apply the
pattern,However this can lead to unwise design
decisions,
? Resolution:
— Always understand in depth the forces that need to
be balanced,and when other patterns better balance
the forces,
— Make sure you justify each design decision carefully.
? Lethbridge/Laganière 2001 Chapter 6,Using design patterns 42
Difficulties and Risks When Creating Class
Diagrams
? Developing patterns is hard
— Writing a good pattern takes considerable work,
— A poor pattern can be hard to apply correctly
? Resolution,
— Do not write patterns for others to use until you
have considerable experience both in software design
and in the use of patterns,
— Take an in-depth course on patterns.
— Iteratively refine your patterns,and have them peer
reviewed at each iteration.