Design

1
1
Design Analysis Patterns
Design Patterns
Introduction to Patterns Constructional
Patterns Other Patterns
2
Design Analysis Patterns
2
Introduction to Patterns
Façade Observer Pattern Visitor
Pattern Adapter/Wrapper Pattern Decorator
Pattern Composite Proxy Pattern Mediator
Bridge
3
3
Design Analysis Patterns
The Façade Pattern
This is one of the simplest patterns and yet one
which is used most often. The main
characteristics are - The complex web of
connections between a systems components are
hidden behind a single class acting as the
façade. The system or sub-system presents a
simple interface to the user code. Changes can
be made easily to the structure of the
sub-system without impacting on the user. In
other words, this represents encapsulation at a
higher level - a system or sub-system level,
rather than at the class level.
4
4
Design Analysis Patterns
The Façade Pattern
A very commonly applied pattern. This takes a
group of closely coupled objects and wraps them
up in a container presenting a single interface
to the clients. (I.e. a black box)
Facade
If one of the components is not suitable as the
façade, a special class is created. E.g. The
Petri-Net simulator



inputs

outputs
5
5
Design Analysis Patterns
Introduction
Code reuse has major benefits in supporting rapid
application development and prototyping, but is
limited because of - Highly specific nature
of code. Operating system platform
dependencies. Making direct reuse difficult
except for very simple components. A more
hopeful form of reuse is the reuse of designs.
Having found a good solution to a class of
problem, the design knowledge can be classified
and recorded for others to take advantage of.
This is the purpose of patterns. Patterns
provide - An aid to the reuse of design and
analysis. A distillation of good
practice. A means of communication between
designers.
6
6
Design Analysis Patterns
The Observer Pattern
This pattern was one of the first to be
recognized as such and came from work by Kay on
Smalltalk in the late 1970s. In its original
form it comprised of three components - A
model - the underlying computational component in
the system. A view - a visual element (GUI)
displaying some aspect of the
models state to the user. A
controller - allowing the user to interact with
the model and change
its state. and was known as Model-View-Controller
(MVC) pattern. The controller part of this
pattern was later seen to not be of particular
interest and combination of Model and View
became known as the Observer pattern.
7
7
Design Analysis Patterns
Separating Model and View
Model - The underlying computational object in
the system - usually invisible to the user.
Implements the systems functionality. View -
A visual representation of part or all of the
state of the model object. Usually an
interface element - e.g. a window containing
graphical or other information A model may
have several different views showing different
factes of its state. Coupling - The direct
approach A reference to each view is held in the
model, which sends a redraw message to each view
when the state of the model changes,
View1
redraw(x,y,z)
Model
redraw(p,q)
View2
8
8
Design Analysis Patterns
Problems with the direct approach
The model knows about all the views. The model
must know what information each view requires to
refresh itself. Any change to the number of
views or their data requirements impacts on the
model. There is a strong coupling between a
model and its views. If we wish to reuse the
model we must either modify it or reuse its views
as well.
9
9
Design Analysis Patterns
The Observer Pattern
Based on the MVC pattern introduced in Smalltalk,
this decouples the Model and View.
ltltinterfacegtgt Observer update()

1.notifyObservers()
View2
View1
Model
2. update()
3. getState()
The Model broadcasts to the views that a change
of state has occurred. Views are responsible for
getting the new information required.
10
10
Design Analysis Patterns
Benefits of the Observer pattern
The model is unaffected by the addition or
removal of views. It is also unaffected by
changing data requirements of views. The model
can be reused independently of the views. Views
can be added/removed at any time, even during
system operation. The broadcast mechanism is
hidden from the model code by being inherited
from the Observable class. The only impact on
the model is the inclusion of a call to
setChanged() and notifyObservers() at points
where the model changes state. This never needs
amendment.
11
11
Design Analysis Patterns
The Visitor Pattern
This pattern provides a way of adding
functionality to a system once it has been
commissioned without having to modify the system
in any way. A Visitor is an object which is
permitted access to a system and can perform a
variety of tasks, such as - Data collection
and and analysis - perhaps concerning
the performance of the system. Carrying out
routine maintenance on the system. Perhaps,
setting policy to modify the behaviour of the
system. Each component in the system has an
accept(Visitor v) method which admits a Visitor
object. The Visitor class is an abstract
super-class from which different types of visitor
can be derived.
12
Design Analysis Patterns
12
The Visitor Pattern - The System
v.visitLibrary(this) for all books
book.accept(v) for all members
member.accept(v)


Member ... accept(Visitor v) ...
Loan ... accept(Visitor v) ...
Book ... accept(Visitor v) ...

0,1
onLoan
v.visitMember(this) for all loans
loan.accept(v)
v.visitLoan(this)
v.visitBook(this)
accept() methods are standard in form and can be
automatically generated. If the Visitor pattern
is not activated there is no system overhead.
13
Design Analysis Patterns
13
The Visitor Pattern - Visitors
numReaders if m.hasLoans() numReading
numBooks if b.onLoan() numOnLoan
ReaderAnalysis int numReaders 0 int
numReading 0 visitLibrary(Library
lib) visitBook(Book b) visitLoan(Loan
ln) visitMember(Member m) double getReaders()
return 100.0 numOnLoan/
numBooks
return 100.0 numReading/
numReaders
14
14
Design Analysis Patterns
The Adapter or Wrapper Pattern
This pattern is used to convert the interface of
a server to a form expected by a client. Useful
when replacing an old server with a new one with
the same functionality but different
interface. There are two approaches to the
implementation of this pattern - A Class
adapter - using multiple inheritance An Object
adapter - using aggregation delegation
Object Adapter
ltltabstractgtgt Server Service()
NewServer NewService()
adaptee.NewService()
15
15
Design Analysis Patterns
The Adapter or Wrapper Pattern
Class Adapter
ltltabstractgtgt Server Service()
NewServer NewService()
Wrapper Service()
NewService()
Important points to note - There is only one
level of nesting (in the object adapter). The
interface of the wrapper differs from that of the
client. There is no added functionality.
16
16
Design Analysis Patterns
The Decorator Pattern
This pattern looks similar to the wrapper pattern
but has some important differences. It is used
to wrap a server object and provide additional
functionality in a way that is transparent to the
client.
ltltabstractgtgt Server Service()
Decorator component Service()
RealServer Service()
extraFunction() component.Service()
17
17
Design Analysis Patterns
Comparison of Decorator Wrapper
It should be noted that these two patterns differ
in a number of ways - Decorators can be nested
- wrappers cant. Decorators add functionality
- wrappers dont. Wrappers transform the server
interface - decorators dont. Using composite
patterns Patterns usually perform a single, well
defined service. In practice, the system under
construction requires combinations or adaptations
of patterns (which should be viewed as building
blocks). E.g. when a new server is installed, we
may wish to monitor its usage to gauge how
effective it is - this requires a combination of
both patterns.
18
18
Design Analysis Patterns
The Composite Pattern
This pattern, which provides for deeply nested
components is a very common one, best illustrated
by reference to GUI components.
ltltabstractgtgt Component paint()
add(Component)

...
Panel paint() add(Component)
ScrollBar paint()
Button paint()
TextField paint()
Canvas paint()
19
19
Design Analysis Patterns
The Proxy Pattern
This pattern provides a surrogate for an object
in place of the real thing. A good example here
is the stub and skeleton used to communicate
between remote objects.
Remote Object Stub service()
Remote Object Skeleton service()
RemoteObject service()
20
20
Design Analysis Patterns
21
21
Design Analysis Patterns
22
22
Design Analysis Patterns
23
23
Design Analysis Patterns
24
24
Design Analysis Patterns
Constructional Patterns
Factory Pattern Abstract Factory
Pattern Builder Pattern Prototype Pattern
25
25
Design Analysis Patterns
Constructional Patterns - Example Problem
The construction of complex objects often entails
a large amount of code and constructional
patterns are an attempt to make such code more
sesilient to change. The following examples are
based on the following system class diagram -
Fire regulations dictate that each floor of
the building is connected to the one below by
two separate staircases.
26
26
Design Analysis Patterns
Constructional Patterns - Example Problem
The Building class could have a createBuilding
method which contains code for the
construction of the building object, perhaps as
follows - Problems with this - Very
long method Specific use of
constructors. The last point makes use of
sub-classes more difficult.
27
27
Design Analysis Patterns
Example Problem - Possible Change
Suppose the model is to be changed to a building
composed of teaching rooms and labs with
computers. The createBuilding method needs
substantial revision -
28
28
Design Analysis Patterns
Example Problem - Use of Factory Methods
One way to make the createBuilding method more
flexible, is to remove the explicit use of
constructors and put them in factory methods as
illustrated here - The unaltered
createBuilding method will now call createRoom to
instantiate ClassRoom instances rather than Room
instances.
29
29
Design Analysis Patterns
Constructional Patterns - Abstract Factory
In the foregoing use of factory methods,
the factory methods and the Building
construction methods were all in the same
class. A cleaner separation is achieved by
putting the factory methods in a separate
factory class.
30
30
Design Analysis Patterns
Example Problem - Builder Pattern
The use of factory methods and the abstract
factory pattern have made it easier to introduce
new sub-classes into the createBuilding
method. It is still very complex due to
the need to explicitly connect up
all the components. This task can be
given to a Builder, allowing the
application to specify what is
required rather than create it.
31
31
Design Analysis Patterns
Example Problem - The Prototype Pattern
This is a very different approach where the
factory class instantiates a single instance of
each type of component. These are used as models
or prototypes from which required objects are
stamped out by copying (or cloning).
32
32
Design Analysis Patterns
Other Patterns
Iterator Pattern Mediator Pattern
33
33
Design Analysis Patterns
The Iterator Pattern
It frequently happens that when we have an object
containing a collection of other objects, it is
desirable to traverse the collection of contained
objects in order to perform some common operation
on them all. This requires the use of an
Iterator. In Java, the pattern is provided for
by the Enumeration interface, which provides
sequential (quasi-file) access to components in
such collections as Hashtables and Vectors.
34
34
Design Analysis Patterns
The Mediator Pattern
It often happens that a group of classes are very
tightly coupled and a complex web of interactions
takes place between them. To simplify the design
it is often desirable to introduce a Mediator
which acts as a coordinator, controlling the
other components -
Setting change
Speed
speed change
GearBox
Throttle
Throttle
power change
speed change
torque change
DriveShaft
DriveShaft
Road
Engine
Mediator
speed change
gradient change
consumption change
GearBox
Engine
Speed
Road
Fuel
Fuel