Rapid Application Development:

design patterns.

J. Baltasar García Perez-Schofield

IMO Group - SI1
 Pattern employment
● Design patterns are, simply, “ways of doing
things.”
● Their objective is twofold:
– Present a solution to a problem, which is adaptable
and scalable to variations in its parameters. For
example, an object collection able to store tens to
thousands of objects.
– These solutions are robust and well-known.
 ¿Design patters = RAD?
● Design patterns are not generally involved in
RAD.
● However, they solve well-known design
problems.
● They reduce the needs of feedback in the life
cycle between the implementation phase and the
design phase, as the solutions they present are
easily adaptable and escalable.
 ¿When should I use patterns?
● Design patterns, as their name mean, are applied
in the design phase. This implies that:
– Analysis phase (what is necessary to do?) is not
covered by design patterns at all.
– Design phase (how should it be solved ?) is quite
covered by this technique.
– Implementation phases and tests are not directly
affected by the use of patterns, thouhg they benefit
from them all (the software is easier to modify and es
más fácil de modificar y ampliar).
 Patterns types
● Creation
– Abstract Factory, Factory Method, Prototype
● Estructural
– Bridge, Facade, Composite, Proxy
● Behavioural
– Chain of responsibility, Iterator, Observer,
TemplateMethod

References:
● http://www.dofactory.com/patterns/
● Gamma, et al. (2003). Patrones de diseño. Addison Wesley.
 Pattern enumeration

● Follows the exposition of various patterns.

● This is a selection of a number of patterns. You
can find more of them in “Design
patterns” (Gamma et al.).
Creation patterns
 Abstract Factory
● Presents a separation between, for example, the
classes related to user interface and the program
itself (i.e., the bussiness logic).
● The central part of this pattern is object creation.
Thus, a source code line such as the following
one in a given method A:
– B * ptrb = new B;
● ... creates an excessive coupling between these
two classes.
● This is solved by means of an object hierarchy,
designed to create other objects (factories).
 Abstract Factory
● The Client class, selects
the specific factory class
at the time of creation.
● It does only keep a
reference to the base
classes ProductA y
ProductB.
● This way, client and
products are totally
independent.
 Abstract Factory

● The typical example of this pattern happens when

an application has to deal with two different
window managers (being compatible with both).
● Thus, the employment of any of these two GUI's
is interchangeable: it is just a matter of selecting
one of the two available classes hierarchy.
 Prototype
● This pattern is designed to deal with the
circumstance in which you need objects of one
class, but its objects are classifiable in some way.
● A good example are the Reversi game pieces.
Each piece does only differenciate from the
others in their color and position. Instead of
creating a piece from scratch, you could clone
another existing one.
 Prototype
● The Client, instead
of creating objects,
clones other
existing ones.
● Note that clone()
should be a
polymorhpic
method, so it won't
be necessary to
know the exact
type of the object.
 Singleton

● This pattern assures that there is only one object

for a given class.
● This is something usual when dealing with
common resources, as for example, main
memory. The resource is encapsulated in a class,
but it is necessary to assure that it will only be an
object of that class.
 Singleton
● Note that the
constructor is a
private method.
● The method
instance()
does only return
a single
instance,
creating it for
the first time if
needed.
Structural patterns
 Adapter
● Encapsultes a class, so its interface can be
normalized for other classes.
● This problem is presented when a previously
existing class is reused for a current project.
● The adapter class gets in the middle of the
communication between the reused class and the
other classes. It presents the interface the other
class expect this class to have, translating all
messages.
 Adapter
● El cliente
("Client"), se
comunica con la
clase adaptadora
que actúa de
intermediaria, en
lugar de con la
clase que
realmente
proporciona la
funcionalidad
("Adaptee").
 Bridge

● The bridge pattern allows to separate two

different aspects of a hierarchy of classes.
● Basically, while a hierarchy implements the core
functionality, others present other aspects, such
as its representation in different media.
 Bridge
● In the example,
there are different
implementations
of a given method
(ConcreteImpleme
ntorA y
ConcreteImplemen
torB).
● The objective is to
separate different
aspects.
 Bridge
● A typical example is to separate the persistence
aspect from its functionality in a hierarchy of
classes.
● While the main hierarchy does only implement
core functionality, the other implements its
representation on disk.
● In some place it will be needed to link the
specific class, so it will be necessary to create a
persistence class for each core class. Sometimes
this can be achieved by using an Abstract Factory
pattern.
 Facade

● Typically, a correct design will lead us to break

functionality in a factorization deeper than
needed.
● In this class, it is possible to build a facade class,
with the expected (simplified) interface which
will communicate with the other classes.
● The facade class Facade
gets in the
middle between
the client (not
shown), and the
other classes in
the subsystem.
● Facade
simplifies the
interface of the
subsystem.
Behavioural patterns
 Chain of responsibility
● Many times, a client needs a function to be
carried out, but it doesn't know the specific server
that would carry it out, or it is preferable to
prevent it from knowing the server, avoiding an
excessive coupling.
● The petition is thrown to an object chain that will
let it pass through until a suitable object can
handle it.
 Chain of responsibility
● The Client, knows
a Handler that
will throw the
petition to the
chain, until a
serve object gets
it.
 Chain of responsibility

● A typical example could be to send a printer job.

The client doesn't know even which printers (if
any) are linked to the system. Eventually, one of
them executes the job.
● There is an obviuos decoupling between the
object that throws the job and the server that
carries it out.
 Iterator
● Is a widely used pattern.
● Many collections (containers such as list,
vector ...), that will be run over with the same
abstraction: the iterator.
● It allows to run over all elements in a container,
sequentally.
● It is frequently present in the STL library of C++.
 Iterator
● The client can
use any given
iterator, without
knowing over
which container
it is running.
 Observer
● An object can notify of a change of itself to all
other (interested) objects.
● It's a way to define a one to many relation.
● A typical example can be found when, having
two different explorer windows over the same
directory, the changes made through one of the
windows is reflected in the other ones. These two
explorers could be defined as two observers of
the file system.
 Observer
● Each observer
can take a
different action
when a change
takes place.