DESIGN PATTERNS
DESIGN PATTERNS
Partial solutions (self-contained components) that are (re)usable in building larger
systems
SOME AREAS OF PATTERN USAGE
A common interface component (allowing different subsystems to co-exist seamlessly)
A wrapper/adapting component (provides plug-ins to sets of legacy or externally
developed subsystems)
An abstract view (encapsulating and hiding the specificities of underlying subsystems)
WHAT IS A DESIGN PATTERN
An software composed of a few classes, which provide interfaces that support
inheritance and delegation mechanisms for ‘gluing’ user developed applications for
constructing large, modularized, component-based software systems. Classes in
patterns can be adapted and refined (effortlessly) to suit various project designs.
ABSTRACT FACTORY PATTERN - Encapsulation
PURPOSE
If developing an application to run on a variety of platforms. Each platform can have
its own specific or concrete environment (CPU type, OS type, DBMS type, GUI type,
etc.), and still, this application can access/interact with each platform (without
changing it each time) THROUGH the Abstract Factory Pattern
DESCRIPTION
Each platform is represented by a Factory class, with concrete subclasses
under it. Each concrete subclass support a platform concept (e.g, window,
button, slider, menu). The Factory class contains methods for ‘creating’ or
‘instantiating’ a concrete type below it Thus, when the platform is changed,
only the Factory class methods have to be reworked to conform to the new
platform(s) concepts.
EXAMPLES
Fig 7-28
Swing – JFC dynamic interface concept modeling
RELATED TO
Other patterns and concepts that foster reuse and hiding/removal of
dependencies (hw and sw)
C l i e n t A b s t r a c t F a c t o r y
c r e a t e W i n d o w ( )
c r e a t e B u t t o n ( )
M o t i f F a c t o r y M a c F a c t o r y
c r e a t e W i n d o w ( ) c r e a t e W i n d o w ( )
c r e a t e B u t t o n ( ) c r e a t e B u t t o n ( )
A b s t r a c t W i n d o w A b s t r a c t B u t t o n
M o t i f W i n d o w M a c W i n d o w M o t i f B u t t o n M a c B u t t o n
Figure 7-28. AbstractFactory design pattern (UML class diagram, dependencies represent >
relationships). This design pattern uses inheritance to support different look and feels (e.g., Motif and Macintosh). If a
new specialization is added, the client does not need to be changed.
THE ADAPTER PATTERN – Legacy Wrapper
PURPOSE
A completely external system (legacy) that is needed to support a new application.
The desire may be to replace the legacy system with, yet, newer or variation of it.
None of these changes should impact the new application.
DESCRIPTION
The new application can call (using a set of calling functions internal to it) the
resources of the legacy system. Of course, the legacy system’s calling-interface has
different syntax and semantics; which are different from the new application’s calling
procedure. An Adapter class serves as the ‘go-between’, by implementing an Interface
using methods from the legacy system. The new application then calls the Interface,
not directly to the legacy system.
EXAMPLES
Fig 6-34, Fig A2
(E.g., NewInterface implements the new-request to sort, passing in its parameters what-
type to sort and the order. The Adaptor implements the MyStringComparator method,
which in turn uses the LegacySystem’s basic sorting operations via calling)
RELATED TO
The Bridge pattern, which bridges that gap between an interface and its
implementation
THE BRIDGE PATTERN – Bridging alternative implementation via single interface
PURPOSE
Situations where ‘choices’ or alternative implementations of an algorithm, e.g., are
desired; but the application need not change for each implementation usage. The
Bridge patter abstracts the implementations’ interface from the application. Thus, the
interface and the implementations are decoupled (either or both can be modified
independently).
DESCRIPTION
First, an ImplementorInterface class is defined with methods, which provide services
to the Abstraction class. (Remember, the application is shielded from the mutations of
the ImplementorInterface through the Abstraction class.) The ImplementorInterface
then subclasses all the possible concrete implementations (via generalization and
inheritance).
EXAMPLES
Fig 6-37, Fig A3
RELATED CONCEPTS
The Adapter Pattern (complementary)
imp
ODBC ODBC Implementation
DB2 ODBC Oracle ODBC Informix ODBC
Driver Driver Driver
Figure 6-37. Bridge pattern for abstracting database vendors (UML class diagram). Removing the dependency from
database vendors from the systems provides more flexibility.
THE COMMAND PATTERN – Encapsulating control (menu-style optioning)
PURPOSE
Isolation/clustering of related set of commands, which the application calls for but only
through the Command abstract class. The Command class maps the called command
into concrete command class. These concrete command classes contain simple
‘execute-type’ methods, which simply invokes the desired/called command in the set.
In this way, command implementations are not scattered across different objects, and
new concrete commands can be added/subtracted without disturbing the application
DESCRIPTION
The Command class interface defines the common services (implemented by all the
concrete commands – more like a menu or list of command prototypes). Applications,
or clients, request for services of interest via the Command abstract class
EXAMPLES
Fig 6-45
RELATED TO
MVC architecture (Fig 6-15)
* * Command
Menu MenuItem
execute()
execute()
Application
Document
CopyCommand
paste() execute()
copy()
PasteCommand
execute()
Figure 6-45. An example of a Command pattern (UML class diagram). In this example, menu items and operations
on documents are decoupled. This enables us to centralize control flow in the command objects (CopyCommand and
PasteCommand) instead of spreading it across boundary objects (MenuItem) and entity objects (Document).
initiator
Controller
1 repository
*
Model
1 notifier
subscriber
View
*
Figure 6-15. Model/View/Controller architecture (UML class diagram). The Controller gathers input from the user
and sends messages to the Model. The Model maintains the central data structure. The View(s) display the Model
and is notified (via a subscribe/notify protocol) whenever the Model is changed.
COMPOSITE PATTERN – Synthesis of systems via recursive hierarchies
PURPOSE
Services in the containment (class) hierarchy are factored out, and reachable via
inheritance. In this way, the leaf nodes (lowest level of the tree-like structure),
implement the modifiable services.
DESCRIPTION
The Composite class (which houses the services) is an aggregate of the services or
leave nodes, where the services are shared. The leave methods do the actual
operation of the services requested.
EXAMPLES
Fig 6-3, Fig 6-8, Fig 12-6
RELATED TO
Façade pattern
S y s t e m P a r t
* *
C l a s s S u b s y s t e m
p a r t s
Figure 6-3. Subsystem decomposition (UML class diagram).
RationaleSubsystem
Figure 6-8. Alternative subsystem assesses
decomposition for the decision tracking Criterion Alternative
system of Figure 6-7 (UML class diagram).
The coherence of the * * *
RationaleSubsystem and the
PlanningSubsystem is higher than the
coherence of the original solvableBy
DecisionSubsystem. Note also that we DesignProblem based-on
also reduced the complexity by
resolvedBy
decomposing the system into smaller
subsystems.
Decision
PlanningSubsystem
implementedBy
SubTask
*
ActionItem Task
subtasks
S o f t w a r e l i f e c y c l e
Figure 12-6. Model of the software life cycle (UML class diagram). A software life cycle
consists of process groups, which in turn consist of processes. A process accomplishes a
* specific purpose (e.g., requirements, design, installation). A process consists of activities,
which are in turn consists of sub-activities or tasks. Tasks represent the smallest piece of
P r o c e s s g r o u p work that is relevant to management. Tasks consume resources and produces one or
more work products. A project is an instance of a software life cycle.
*
P r o c e s s
*
P h a s e *
W o r k P r o d u c t
* p r o d u c e s
c o n s u m e s
A c t i v i t y T a s k
*
R e s o u r c e
P a r t i c i p a n t
T i m e
M o n e y
THE FAÇADE PATTERN – Presenting a unified interface for subsystems
PURPOSE
Reduces dependencies among classes by presenting a unified interface to
encapsulated subsystems. (E.g., A compiler application with many subsystems, using
the Compiler via a Façade pattern will provide a high level interface to the compiler
DESCRIPTION
Lower level class (subclasses) in, e.g., the compiler application, can be invoked via the
high-level interface. An Façade is opaque (I.e., black-box like) in that a caller
accesses the subclass services/methods indirectly.
EXAMPLE
Fig 6-30, (Fig A-6)
RELATED TO
Fosters coupling and cohesion, layering and partitioning of systems. Complements the
Composite Pattern
Compiler Compiler
compile(s)
CodeGenerator Lexer
create()
getToken()
Optimizer Parser
create() generateParseTree()
ParseNode
create()
Figure 6-30. An example of the Facade pattern (UML class diagram).
OBSERVER PATTERN – Presenting multiple views through a single entry (subscriber)
PURPOSE
Many viewers see specific subscriptions/views through a single Subscriber abstract
class. The Subscriber is capable of presenting multiple views or displays of the same
information for different viewers or audiences.
DESCRIPTION
Using invoke() and update() methods between the viewers (e.g., publisher class
objects) and the subscriber objects, the concrete views (or concrete subscribers) can
be modified to allow synchronization or consistency between the viewers and the
subscriber-objects.
EXAMPLE Fig 6-15
RELATED TO
Entity, interface and control objects
initiator
Controller
1 repository
*
Model
1 notifier
subscriber
View
*
Figure 6-15. Model/View/Controller architecture (UML class diagram). The Controller gathers input from the user
and sends messages to the Model. The Model maintains the central data structure. The View(s) display the Model
and is notified (via a subscribe/notify protocol) whenever the Model is changed.
THE PROXY PATTERN – Deferring expensive services
PURPOSE
Services which require expensive computation or memory usage are deferred. A
preliminary (preparatory or evaluative service is provided) service is provided by the
Proxy class, before the Real class services are invoked.
DESCRIPTION
The Proxy and the Real classes both implement the same interface, but the Proxy is
more skeletal, having a subset of the Real class’s attributes, evaluates certain requests
completely on its own, and then delegates the heavyweight services to the Real class
EXAMPLES
Fig 7-31, Fig A8, Client-Server systems, Windowing systems
RELATED CONCEPTS
Caching expensive computations (look-ahead techniques)
o o
Ob ject design mod el bef re transf rmation o
Ob ject design mod el after transf rmation
Image I m a g e
f i l e n a me:String f i l e n a m e : S t r i n g
d a t a : b yte[] w i d t h ( )
w i d t h ( ) h e i g h t ( )
h e i g h t () p a i n t ( )
p a i n t ( )
i m a g e
I m a g e P r o x y R e a l I m a g e
1 0 . . 1
f i l e n a m e : S t r i n g d a t a : b y t e [ ]
w i d t h ( ) w i d t h ( )
h e i g h t ( ) h e i g h t ( )
p a i n t ( ) p a i n t ( )
Figure 7-31. Delaying expensive computations using a Proxy pattern (UML class diagram).
THE STRATEGY PATTERN – Encapsulating multiple implementation of algorithms
PURPOSE
Decouples an algorithm from its many implementations. Similar to the adaptor and
bridge patterns, only that a Strategy pattern encapsulates the behaviors of a single
object – an algorithm
DESCRIPTION
An abstract Strategy class provides an interface to concrete strategy classes, which
implement the various behaviors of that single algorithm. The concrete
implementations can be switched with impacting the caller application
EXAMPLES
Fig 6-40, Fig A9
RELATED TO
Adapter and Bridge Patterns
Strategy class
Message IDEA
getBlock() encrypt(key, block)
decrypt(key, block)
Context class ConcreteStrategy
classes
IDEA_Vendor_A IDEA_Vendor_B
Figure 6-40. An example of a Strategy pattern encapsulating multiple implementation of the IDEA encryption
algorithm (UML class diagram). The Message and IDEA classes cooperate to realize the encryption of plain text. The
selection of an implementation can be done dynamically.