Design Pattern Matrix

Design Patterns: From

Analysis to Implementation
by

This is an excerpt from the manuals for

Design Patterns Explained: A New Perspective for Object-Oriented Design

Not all of the Gang of Four design patterns are included because not all of them are covered in
the course. Furthermore, we use a variation on the classification of the GoF patterns:
The Decorator and Proxy patterns are classified as Structural patterns by the GoF. Since they both add
instead of just combining functionality, I believe they are more behavioral in nature. In our minds, the Bridge
can be considered as either a Structural or Behavioral pattern. As a structural pattern, it allows the use of
two different, given, implementation in the same way. As a behaviorally pattern, it helps identify that there
are variations of an implementation. We have also reclassified several Behavioral patterns as Decoupling
patterns (a new classification of ours). That is because these patterns are more about decoupling than about
managing new behavior.

This is a work in progress. Updates will be announced through our e-zine. You can subscribe
to this by sending a message to [email protected] and putting subscribe in the subject.

Contents:
Abstract Factory* Composite* Visitor
Builder Façade* Chain of Responsibility*
Factory Method* Proxy – Virtual* Iterator*
Object Pool* Decorator* Mediator*
Prototype Proxy – adding function* Memento
Singleton* State* Observer*
Adapter* Strategy* Proxy – accessibility*
Bridge* Template Method* Model-View-Controller

* Along with the Analysis Matrix, these are considered minimal competencies for software
developers by Net Objectives

© 2007 Net Objectives, Inc. All Rights Reserved 1

Design Pattern Matrix
CREATIONAL PATTERNS
Notes on the patterns
A F Indicators in analysis: Different cases exist that require different implementations of sets of rules.
b a Indicators in design: Many polymorphic structures exist that are used in pre-defined combinations. These combinations are
s c defined by there being particular cases to implement or different needs of client objects.
t t Indication pattern is not being used when it should be: A variable is used in several places to determine which object to
r o instantiate.
a r Relationships involved: The Abstract Factory object is responsible for coordinating the family of objects that the client object
needs. The client object has the responsibility for using the objects.
c y
t Principle manifested: Encapsulate construction.

Indicators in analysis: Several different kinds of complex objects can be built with the same overall build process, but where
B there is variation in the individual construction steps.
u Indicators in design: You want to hide the implementation of instantiating complex object, or you want to bring together all of the
rules for instantiating complex objects.
i
l
d
e
r
Indicators in analysis: There are different commonalities whose implementations are coordinated with each other.
F M Indicators in design: A class needs to instantiate a derivation of another class, but doesn’t know which one. Factory method
a e allows a derived class to make this decision.
c t Field notes: The Factory method is often used with frameworks. It is also used when the different implementations of one class
t h hierarchy requires a specific implementation of another class hierarchy. Note that a factory method pattern is not simply a method
that serves as a factory. The pattern specifically involves the case where the factory is varied polymorphically. Factory Method is
o o also very useful when unit testing with Mock Objects.
r d Principle manifested: Encapsulate the relationship between class hierarchies.
y
Indicators in analysis: There are rules about how to manage a set of objects. These can relate to the number, the lifespan,
O P handling error conditions, load balancing and more.
b o Indicators in design: There are rules about creating and managing your objects.
j o Field notes: The object pool is a great way to defer the management of the lifespan of your objects. Use some trivial to implement
e l rule, but encapsulate it in the object pool. Once you have the system working and you better understand the rules for object
creation and management, implement these rules in the encapsulated methods.
c
t

P Indicators in analysis: There are prototypical instances of things.

r Indicators in design: When objects being instantiated need to look like a copy of a particular object. Allows for dynamically
o specifying what our instantiated objects look like.
t
o
t
y
p
e
S Indicators in analysis: There exists only one entity of something in the problem domain that is used by several different things.
i Indicators in design: Several different client objects need to refer to the same thing and we want to make sure we don’t have more
than one of them. You only want to have one of an object but there is no higher object controlling the instantiation of the object in
n
questions.
g Field notes: You can get much the same function as Singletons with static methods, however using static methods eliminates the
l possibility of handing future change through polymorphism, and also prevents the object from being passed by reference,
e serialized, remoted, etc… in general, statics are to be avoided if possible. Also, keep in mind that a stateful Singleton is
t essentially a global, and thus can potentially create coupling from any part of your system to any other part, so they should be used
o with care. Stateless Singletons do not have this problem.
n

© 2007 Net Objectives, Inc. All Rights Reserved 2

Design Pattern Matrix
CREATIONAL PATTERNS
How it is implemented + what it encapsulates Class Diagram/Implementation
Define an abstract class that specifies which objects are to be Client A F
made. Then implement one concrete class for each family. Tables WidgetFactory
Window
b a
or files can also be used to essentially accomplish the same thing.
Names of the desired classes can be kept in a database and then
+ createWindow()
+ createScrollBar()
s c
switches or dynamic class loading can be used to instantiate the
PMWindow MotifWindow
t t
correct objects.
MotifFactory PMFactory ScrollBar
r o
a r
Encapsulates: The rules about what our families of objects are – + createWindow() + createWindow()

that is, which ones go together.

+ createScrollBar() + createScroll Bar() c y
PMScrollBar MotifScrollBar
t
Create a factory object that contains several methods. Each Director
method is called separately and performs a necessary step in the + construct() B
building process. When the client object is through, it calls a Builder

method to get the constructed object returned to it. Derive classes + buildStep1() u
+ buildStep2()
from the builder object to specialize steps.
builder->buildStep1()
builder->buildStep2() + getObject() i
getObject() l
Encapsulates: Rules for constructing complex objects. d
ConcreteBuilder1 ConcreteBuilder2 e
+ buildStep1() + buildStep1()
+ buildStep2() + buildStep2() r
+ getObject() + getObject()

Have a method in the abstract class that is abstract (pure virtual). Application
Document
The abstract class’s code will refer to this method when it needs to + createDocument() F M
instantiate a contained object. Note, however, that it doesn’t know
which one it needs. That is why all classes derived from this one
must be
abstract
a e
must implement this method with the appropriate new command to c t
instantiate the proper object. MyDoc MyAp t h
+ createDocument() return new MyDoc
o o
Encapsulates: How two inheritance hierarchies are related to each
other.
r d
Note: in this example createDocument is called a
factory method. Application is not a factory object.
y
Create a class (“ReusablePool”) that encapsulates all of the rules
for creating and managing the pooled objects. This class has only +client
O P
one instantiation (use Singleton to enforce this). When a new Client
1 +manager

pooled object is needed, the ReusablePool is asked to provide it. It 1

0..* b o
also is told when the object is no longer needed so it can be
ReusablePool
-ReusablePool()
j o
returned to the shared pool. Uses
+getInstance()
+acquireReusable() : Reusable e l
+releaseReusable(in : Reusable)
+setMaxPoolSize(in maxSize : int) c
Encapsulates: The rules for creating and managing a set of *

objects.
0..* 1 t
Reusable

Set up concrete classes of the class needing to be cloned. Each Client P

concrete class will construct itself to the appropriate value r
(optionally based on input parameters). When a new object is use clone to instantiate
Prototype o
needed, clone an instantiation of this prototypical object. + clone() t
Encapsulates: The default settings of an object when instantiated. o
ConcretePrototype1 ConcretePrototype2 t
+ clone() + clone() y
return copy return copy p
of self of self
e
Add a static member to the class that refers to the first instantiation PSEUDO CODE (Java) S
of this object (initially it is null). Then, add a static method that i
instantiates this class if this member is null (and sets this class Singleton {
public static Singleton Instance(); n
member’s value) and then returns the value of this member.
Finally, set the constructor to protected or private so no one can
protected Singleton(); g
private static _instance= null;
directly instantiate this class and bypass this mechanism. l
Singleton Instance () { e
Encapsulates: That there is only one of these objects allowed. if _instance== null) t
_instance= new Singleton;
return _instance
o
} } n

© 2007 Net Objectives, Inc. All Rights Reserved 3

Design Pattern Matrix
STRUCTURAL PATTERNS
Notes on the patterns
Indicators in analysis: Normally don’t worry about interfaces here, so don’t usually think about it. However, if you know some
A existing code is going to be incorporated into your system, it is likely that an adapter will be needed since it is unlikely this pre-
existing code will have the correct interface.
d
Indicator in design: Something has the right stuff but the wrong interface. Typically used when you have to make something
a that’s a derivative of an abstract class we are defining or already have.
p
Field notes: The adapter pattern allows you to defer concern about what the interfaces of your pre-existing objects look like since
t you can easily change them. Also, adapter can be implemented through delegation (run-time) or through multiple inheritance
e (C++). We call these variations Object Adapter, and Class Adapter, respectively.
r Principle Illustrated: Make interfaces work for you, not against you. If you don’t have what you want – you can change it
easily.

Indicators in analysis: There are a set of related objects using another set of objects. This second set represents an
implementation of the first set. The first set uses the second set in varying ways.
Indicators in design: There is a set of derivations that use a common set of objects to get implemented.
B Indication pattern is not being used when it should be: There is a class hierarchy that has redundancy in it. The redundancy is
r in the way these objects use another set of object. Also, if a new case is added to this hierarchy or to the classes being used, that
i will result in multiple classes being added.
d Relationships involved: The using classes (the GoF’s “Abstraction”) use the used classes (the GoF’s “Implementation”) in
g different ways but don’t want to know which implementor is present. The pattern “bridges” the what (the abstraction) to the how
(the implementation).
e Field notes: Although the implementer to use can vary from instance to instance, typically only one implementer is used for the
life of the using object. This means we usually select the implementer at construction time, either passing it into the constructor
or having the constructor decide which implementer should be used.
C Indicators in analysis: There are single things and groups of things that you want to treat the same way. The groups of things
o are made up of other groups and of single things (i.e., they are hierarchically related).
Indicators in design: Some objects are comprised of collections of other objects, yet we want to handle all of these objects in the
m same way.
p Indication pattern is not being used when it should be: The code is distinguishing between whether a single object is present
o or a collection of objects is present.
s Variation encapsulated: Whether an item is a single entity or whether it is composed of several sub-components.
Field notes: Whether or not to expose an interface that would allow the client to navigate the composite is a decision that must be
i considered. The ideal composite would hide its structure, and thus the navigation would not be supported, but specifics in the
t problem domain often do not allow this. Often, using a Data Object can eliminate the need for traversal by the client
e

Indicators in analysis: A complex system will be used which will likely not be utilized to its full extent.
Indicators in design: Reference to an existing system is made in similar ways. That is, you see combinations of calls to a system
repeated over and over again.
F Indication pattern is not being used when it should be: Many people on a team have to learn a new system although each
a person is only using a small aspect of it.
ç Field notes: Not usually used for encapsulating variation, but different facades derived from the same abstract class can
a encapsulate different sub-systems. This is called an encapsulating façade. The encapsulating facade can have many positive
side-effects, including support for demonstration/limited function versions of an application.
d Essence of Pattern: Don’t settle for complex – make it simple.
e

Indicators in analysis and design: Performance issues (speed or memory) can be foreseen because of the cost of having objects
around before they are actually used.
Indication pattern is not being used when it should be: Objects are being instantiated before they are actually used and the
P V extent of this is causing performance problems.
r i Variation encapsulated: Although each proxy contains only one new function or way of connecting to the proxy object, this
o r function can be changed (statically) in the future without affecting those objects that use the proxy.
x t Field notes: This pattern often comes up to solve scalability issues or performance issues that arise after a system is
y u working.
a
l

© 2007 Net Objectives, Inc. All Rights Reserved 4

Design Pattern Matrix
STRUCTURAL PATTERNS
How it is implemented + what it encapsulates Class Diagram
Contain the existing class in another class. Have the containing
class match the required interface and call the contained class’s Client TargetAbstraction
+ operation() A
methods
d
Encapsulates that another class has the wrong interface. a
Adapter ExistingClass p
+ operation() + itsOperation() t
e
operation: r
existingclass->itsOperation

Encapsulate the implementations in an abstract class and contain a

handle to it in the base class of the abstraction being implemented. Abstraction Implementation
In Java can also use interfaces instead of an abstract class for the + operation() + opImp1()
implementation. + opImp2()
B
r
Encapsulates dependent/nested variations of function. i
Concrete1 Concrete2
ImpA ImpB d
operation() { operation() {
+ opImp1() + opImp1() g
+ opImp2() + opImp2()
imp.opImp1() imp.opImp2() e
} }

Set up an abstract class that represents all elements in the C

hierarchy. Define at least one derived class that represents the o
individual components. Also, define at least one other class that Client Component
represents the composite elements (i.e., those elements that contain + operation()
m
multiple components). In the abstract class, define abstract p
methods that the client objects will use. Finally, implement these o
for each of the derived classes. s
Encapsulates the structure of a complex collection.
i
Leaf Composite
t
+ operation() + operation()
e

Define a new class (or classes) that has the required interface.
Have this new class use the existing system.
Client
Encapsulates the true nature of a sub-system. F
Facade ComplexSysA a
ç
a
provides simpler ComplexSysB d
interface
e

The Client refers to the proxy object instead of an object from the
Client Abst ract
original class. The proxy object remembers the information to proxy P V
required to instantiate the original class but defers its instantiation. + operation()
When the object from the original class is actually needed, the r i
proxy object instantiates it and then makes the necessary request to o r
it. x t
Virt ualSubject RealSubject
y u
Encapsulates the deferring of some action (e.g., instantiation, + operation() + operation()
making a connection) and the rule(s) to manage it.
- a
realsubject->operation() l

© 2007 Net Objectives, Inc. All Rights Reserved 5

Design Pattern Matrix
BEHAVIORAL PATTERNS
Notes on the patterns
D Indicators in analysis: There is some action that is always done, there are other actions that may need to be done.
e Indicators in design: 1) There is a collection of actions; 2) These actions can be added in any combination to an existing
function; 3) You don’t want to change the code that is using the decorated function.
c Indication pattern is not being used when it should be: There are switches that determine if some optional function should
o be called before some existing function.
r Field notes: This pattern is used extensively in the JDK and .NET for I/O. Note the decorators can be one-way (void return) or
a bucket-brigade (pass down the chain, then "bubble" back up). The Decorator Pattern should be thought of as a collection of
optional behavior preceding the always done “ConcreteComponent”. The form of this collection does not have to be a linked-
t list, but it does have to have the same interface as the “ConcreteComponent” so the Client is unaware that the
o “ConcreteComponent” is being decorated.
r
P F Indicators in design: We need some particular action to occur before some object we already have is called.
r u Indication pattern is not being used when it should be: We precede a function with the same code every time it is used. Or,
we add a switch to an object so it sometimes does some pre-processing and sometimes doesn’t.
o n Variation encapsulated: Although each proxy contains only one new function or way of connecting to the proxy object, this
x c function can be changed (statically) in the future without affecting those objects that use the proxy.
y t Field notes: Proxies are useful to encapsulate a special function that is sometimes used prior to calling an existing object.
| i
N o
e n
w
Indicators in analysis and design: We have behaviors that change, depending upon the state we are in.
Indication pattern is not being used when it should be: The code keeps track of the mode the system is in. Each time an
event is handled, a switch determines which code to execute (based on the mode the system is in). The rules for transitioning
S between the patterns may also be complex.
t Field notes:
a We define our classes by looking at the following questions:
t 1. What are our states?
2. What are the events we must handle?
e 3. How do we handle the transitions between states?

S Indicators in analysis: There are different implementations of a business rule.

t Indicators in design: You have a place where a business rule (or algorithm) changes.
Indication pattern is not being used when it should be: A switch is present that determines which business-rule to use. A
r class hierarchy is present where the main difference between the derivations is an overridden method.
a Relationships involved: An object that uses different business rules that do conceptually the same thing (Context-Algorithm
t relationship). A client object that gives another object the rule to use (Client-Context relationship).
e Variation encapsulated: The different implementations of the business rules.
Field notes: The essence of this pattern is that the Context does not know which rule it is using. Either the Client object gives
g the Context the Strategy object to use, the Context asks a factory (or configuration) object for the correct Strategy object to use,
y or the Context is built by a factory with the right Strategy object to use…or a combination of these approaches. Reduced
intimacy between the context and the algorithm can make Strategy challenging at times.
T M Indicators in analysis: There are different procedures that are followed that are essentially the same, except that each step does
e e things differently.
Indicators in design: You have a consistent set of steps to follow but individual steps may have different implementations.
m t Indication pattern is not being used when it should be: Different classes implement essentially the same process flow.
p h Variation encapsulated: Different steps in a similar procedure.
l o Field notes: The template pattern is most useful when it is used to abstract out a common flow between two similar processes.
a d
t
e
Indicators in analysis and design: You have a reasonably stable set of classes for which you need to add new functions. You
V can add tasks to be performed on this set without having to change it.
Variation encapsulated: A set of tasks to run against a set of derivations.
i Field notes: This is a useful pattern for writing sets of tests that you can run when needed. The potential for change in the class
s structure being visited must be considered – Visitor has maintenance issues when the visited classes change. Adding Visitors in
i the future, on the other hand, tends to be quite easy.
t
o
r

© 2007 Net Objectives, Inc. All Rights Reserved 6

Design Pattern Matrix
BEHAVIORAL PATTERNS
How it is implemented Class Diagram
Set up an abstract class that represents both the original class and Client Component D
the new functions to be added. Have each contain a handle to an + operation() e
1
object of this type (in reality, of a derived type). In our decorators,
perform the additional function and then call the contained c
object’s operation method. Optionally, call the contained object’s ConcreteComponent Decorator 0..1 o
operation method first, then do your own special function. + operation() + operation()
component.operation() r
a
Encapsulates the sequence, cardinality and even the existence of
optional behaviors.
ConcreteDec1 ConcreteDec2 addedBehavior() t
Decorat or: :operation()
+ operation() + operation()
o
r
The Client refers to the proxy object instead of an object from the P F
Client A bs tract
original class. The proxy object creates the RealSubject when it is to proxy
r u
+ op erat ion ()
created. Requests come to the Proxy, which does its initial
function (possibly), passes the request (possibly) to the o n
RealSubject and then does (possibly) some post processing. x c
P rox y RealS ubject y t
Encapsulates the new function required by the client. + operation() + operation() | i
N o
real subj ec t-> operation()
e n
w
Define an abstract class that represents the state of an application. Client
Context State
Derive a class for each possible state. Each of these classes can + request(Strategy) + event()
now operate independently of each other. State transitions can be
handled either in the contextual class or in the states themselves. S
Information that is persistent across states should be stored in the stat e->event () t
StateMode1 StateMode2
context. States likely will need to have access to this (through get + event() + event()
a
routines, of course). t
Encapsulates the states (or modalities) of a system and how it
e
transitions from one to another.

Have the class that uses the algorithm contain an abstract class that S
Client
has an abstract method specifying how to call the algorithm. Each t
derived class implements the algorithm as needed. Context Strategy
+ request(Strategy) + algorithm()
r
Encapsulates that there are multiple algorithms. a
t
e
StrategyA StrategyB g
+ algorithm() + algorithm()
y
Create an abstract class that implements a procedure using abstract AbstractTemplate T
methods. These abstract methods must be implemented in derived Client + templateMethod() e M
classes to actually perform each step of the procedure. If the steps + operation1() templateMethod:
vary independently, each step may be implemented with a strategy + operation2() ... m e
pattern.
operation1()
...
p t
operation2() l h
Encapsulates the different implementations of the method. ...
ComcreteClass a o
+ operation1()
+ operation2()
t d
e
Make an abstract class that represents the tasks to be performed. AbstractTask Client Structure
Add a method to this class for each concrete class you started with + visitElTypeA()
V
(your original entities). Add a method to the classes that you are + visitElTypeB()

working on to call the appropriate method in this task class, giving i

Element
a reference to itself to this method. TaskA TaskB + accept(task)
s
+ visitElTypeA(typeA)
+ visitElTypeB(typeB)
+ visitElTypeA(typeA)
+ visitElTypeB(typeB)
i
Encapsulates additional functions added to a class hierarchy. t
ElementTypeA ElementTypeB
+ accept(task) + accept(task) o
accept: accept: r
task->visitTypeA(this) task->visitTypeB(this)

© 2007 Net Objectives, Inc. All Rights Reserved 7

Design Pattern Matrix
DECOUPLING PATTERNS
Notes on the patterns
C s Indicators in analysis: We have the several actions that may be done by different things.
h p Indicators in design: We have several potential candidates to do a function. However, we don’t want the client object to know
a o which of these objects will actually do it.
i n
Field notes: This pattern can be used to chain potential candidates to perform an action together. A variation of Chain of
n s
i Responsibility is to not stop when one object performs its function but to allow each object to do its action. Factories are useful
o b when chains have dependencies and business rules that specific a particular order for the objects in the chain.
f i
l
R i
e t
- y
I Indicators in analysis and design: We have a collection of things but aren’t clear what the right type of collection to use is.
t You want to hide the structure of a collection. Alternatively, you need to have variations in the way a collection is traversed.
Indication pattern is not being used when it should be: Changing the underlying structure of a collection (say from a vector
e to a composite) will affect the way the collection is iterated over.
r Variations encapsulated: Type of collection used.
a Field notes: The Iterator pattern enables us to defer a decision on which type of collection structure to use.
t
o
r

M Indicators in analysis and design: Many objects need to communicate with many other objects yet this communication cannot
e be handled with the observer pattern.
Indication pattern is not being used when it should be: The system is tightly coupled due to inter-object communication
d requirements.
i Field notes: When several objects are highly coupled in the way they interact, yet this set of rules can be encapsulated in one
a place. Mediator can be useful in decoupling tool-generated code (GUI's and database connections, for example) from hand-
t crafted code, and can also help in making dependent objects more testable.
o
r
Indicators in analysis and design: The state of an object needs to be remembered so we can go back to it (e.g., undo an
M action).
Indication pattern is not being used when it should be: The internal state of an object is exposed to another object. Or,
e copies of an object are being made to remember the object’s state, yet this object contains much information that is not state
m dependent. This means the object is larger than it needs to be or contains an open connection that doesn’t need to be
e remembered.
n Field notes: This pattern is useful when making copies of the object whose state is being remembered would be inefficient. It's
also commonly used to create "multiple undo levels". The use of inner classes can help to make Mementos robust, since it
t prevents a memento generated by one instance being applied accidentally to another.
o

O Indicators in analysis and design: Different things (objects) that need to know when an event has occurred. This list of
b objects may vary from time to time or from case to case.
Indication pattern is not being used when it should be: When a new object needs to be notified of an event occurring the
s programmer has to change the object that detects the event.
e Variation encapsulated: The list of objects that need to know about an event occurring.
r Field notes: This pattern is used extensively in the JFC for event handling and is supported with the Observable class and
v Observer interface. Also note that C# multicast delegates are essentially implementations of the Observer pattern.
Essence of pattern: 1) there is a changing list of observers, 2) all observers have the same interface, 3) it is the observers
e responsibility to register it the event they are ‘observing’
r
P c Indicators in analysis and design: Are any of the things we work with remote (i.e., on other machines)? An existing object
r e needs to use an object on another machine and doesn’t want to have to worry about making the connection (or even know about
o s the remote connection).
x i Indication pattern is not being used when it should be: The use of an object and the set-up of the connection to the object are
y b found together in more than one place.
| i Variation encapsulated: Although each proxy contains only one new function or way of connecting to the proxy object, this
l function can be changed (statically) in the future without affecting those objects that use the proxy.
A i Field notes: The Proxy is a useful pattern to use when it is possible a remote connection will be needed in the future. In this
c t case, only the Proxy object need be changed - not the object actually being used.
- y

© 2007 Net Objectives, Inc. All Rights Reserved 8

Design Pattern Matrix
DECOUPLING PATTERNS
How it is implemented Class Diagram
Define an abstract class that represents possible handlers of a function. C s
This class contains a reference to at most one other object derived from h p
this type. Define an abstract method that the client will call. Each derived Client Handler a o
i n
class must implement this method by either performing the requested
+ handleRequest() n s
operation (in its own particular way) or by handing it off to the Handler it i
refers to. Note: it may be that the job is never handled. You can o b
implement a default method in the abstract class that is called when you f i
reach the end of the chain. l
Handler_A Handler_B
R i
Encapsulates both which services are available and the preference of + handleRequest() + handleRequest()
e t
which service to do the task. - y
Define abstract classes for both collections and iterators. Have each Collection Iterator I
derived collection include a method which instantiates the appropriate + createIterator() Client + first()
t
iterator. The iterator must be able to request the required information + append() + next()

from the collection in order to traverse it appropriately.

+ remove() + currentItem() e
r
Encapsulates the nature of a collection. Vector IteratorVector a
List IteratorList t
o
r
Define a central class that acts as a message routing service to all other aColleague M
classes. aColleague
e
Encapsulates the dependencies between objects. d
aMediator i
a
t
aColleague aColleague
o
r
Define a new class that can remember the internal state of another object. Caretaker
The Caretaker controls when to create these, but the Originator will M
actually use them when it restores its state. Originator
e
+ setMemento(m : Memento) Memento
Encapsulates the internal state of an object. + createMemento() m
+ getState() e
Originator creates memento and can later
n
ask it for information about an earlier state. t
o
Have objects (Observers) that want to know when an event happens, O
Subject Observer
attach themselves to another object (Subject) that is actually looking for it attach/detach
b
+ attach() + update()
to occur. When the event occurs, the subject tells the observers that it + detach()
occurred. The Adapter pattern is sometimes needed to be able to + notify()
s
implement the Observer interface for all the Observer type objects. e
ObserverA ObserverB r
Encapsulates who is dependent upon an event that an object looks for. + update() + update() v
notify:
for all observers: e
call update()
Use adapters if observers r
have different interfaces

The Proxy pattern has a new object (the Proxy) stand in place of another, P c
Client Abstract
already existing object (the Real Subject). The proxy encapsulates any to proxy r e
+ operation()
rules required for access to the real subject. The proxy object and the real o s
subject object must have the same interface so that the Client does not x i
need to know a proxy is being used. Requests made by the Client to the y b
proxy are passed through to the Real Subject with the proxy doing any Proxy_Remote RealSubject | i
necessary processing to make the remote connection. + operation() + operation() l
A i
Encapsulates how to access an object. realsubject->operation() c t
- y

© 2007 Net Objectives, Inc. All Rights Reserved 9

Design Pattern Matrix
MODEL VIEW CONTROLLER and ANALYSIS MATRIX
Model-
View- Observer
Observer
Controller
subject + update()

Mo del
View ConcreteObservers
- CoreData
- SetOfObservers - my Model
- my Cont roller
+ attach(Observer) get
attac
data
h
+ detach(Observer) + initializ e(Model)
+ notify() + makeController()
+ getData() + ac tivate()
+ display() display Controller
+ update ()
- myModel
- myView
service
+ initialize(Model, View)
there is no concrete subject in attach + handleEvent()
this exam ple + update()

The Model-View-Controller (MVC) is primarily used when building GUIs. However, it can be used
anytime you have an interactive type system. It is used to de-couple your data, your presentation of the
data and the logic for handling the events from each other.

The Use the Analysis matrix to collect variation between the different cases you have to deal with. Do not try
Analysis to make designs from it while you are collecting it. However, the consistencies and inconsistencies
Matrix between the cases will give you clues. Remember, we will implement the rows as Strategies, Proxies,
Decorators, Bridges, etc. We will implement the columns with the Abstract Factory.
Case 1 Case 2 Case 3 Case 4
one thing that These are the concrete implementations for the ways to whatever is
is varying varying that is listed on the left.

another thing These are the concrete implementations for the ways to whatever is
that varies varying that is listed on the left.

still another These are the concrete implementations for the ways to whatever is
thing that varying that is listed on the left.
varies

… …

Case 1 Case 2 Case 3 Case 4

one thing that is
varying
mentations are used
mentations are used

mentations are used

mentations are used

another thing that

when have case 2
when have case 1

when have case 3

when have case 4

varies
still another thing
These imple-
These imple-

These imple-

These imple-

that varies
…

© 2007 Net Objectives, Inc. All Rights Reserved 10

Design Pattern Matrix
THINGS TO LOOK FOR

Guide to finding patterns in the problem domain

Is there variation of a business rule or an implementation?
Do we need to add some function?

Strategy – do we have a varying rule?

Bridge – do we have one variation using another variation in a varying way?
Proxy – do we need to optionally add some new functionality to something that already exists?
Decorator – do we have multiple additional functions we may need to apply, but which and how many we add
varies? Do we need to capture an order dependency for multiple additional functions?
Visitor – do we have new tasks that we will need to apply to our existing classes?

Are you concerned with interfaces, changing, simplifying or handling disparate type objects in the same way?

Adapter – do we have the right stuff but the wrong interface? (Used to fit classes into patterns as well)
Composite – do we have units and groups and want to treat them the same way?
Façade – do we want to simplify, beautify, or OO-ify an existing class or syb-system?

Are we trying to decouple things?

Observer – do various entities need to know about events that have occurred?
Chain of Responsibility – do we have different objects that can do the job but we don’t want the client object know
which is actually going to do it?
Iterator – do we want to separate the collection from the client that is using it so we don’t have to worry
about having the right collection implementation?
Mediator – do we have a lot of coupling in who must talk to who?
State – do we have a system with lots of states where keeping track of code for the different states is difficult?

Are we trying to make things?

Abstract Factory – do we need to create families (or sets) of objects?

Builder - do we need to create our objects with several steps?
Factory Method – do we need to have derived classes figure out what to instantiate?

Remember the relationship between commonality/variability analysis, the conceptual, specification, implementation
perspectives and how these are implemented in object-oriented languages.

by looking at what
Commonality Conceptual Abstract
these objects must do
analysis perspective class
(conceptual perspective)
Operations we determine how to
call them (specification
perspective)
Specification
perspective Concrete Concrete
class class

Operations Operations
Variability Implementation
When implementing these classes, ensure that
analysis perspective
the API provides sufficient information to
enable proper implementation and decoupling

© 2007 Net Objectives, Inc. All Rights Reserved 11

Design Pattern Matrix
Comparing patterns
Comparing Adapter, Façade, Proxy and Decorator

?
Client Pre-Existing

which pattern?

Adapter Façade Proxy Decorator

Have pre-existing stuff? Yes Yes Yes Yes

Is the client object expecting a Yes No Yes Yes

particular interface?
Want to make a new interface to No Yes No No
simplify things?
Modifying interface to what the client Yes No No No
objects expect?
Want some new function before or Maybe, but not Maybe, but not Yes Yes
after the normal action? the intent the intent (statically) (dynamically)

Comparing Strategy and Bridge

Strategy Bridge State
Contains base class with derivations? Yes Yes Yes

Number of public methods in used 1 1-n 1-n

classes?
Number of classes using the used 1 1-n 1
classes.
Does implementation used change from Usually No Yes
call to call?
Who decides which implementation to Client or config Client, config or Context, States,
use? constuctor or Transition
Method
Does current implementation have No No Yes
impact on next?

Comparing Bridge and Visitor

The Bridge Pattern is about how to have different implementations of the same functionality for a group of related objects
(the derivations of the “Abstraction”). The Visitor Pattern is about how to add new functionality to a group of related objects
(the derivations of the “Structure”).

© 2007 Net Objectives, Inc. All Rights Reserved 12

Design Pattern Matrix

Comparing Decorator, Proxy, and Chain of Responsibility

© 2007 Net Objectives, Inc. All Rights Reserved 13

Design Pattern Matrix

Experts in Agile Training / Coaching

All of our staff are practitioners who know how to teach and coach. This enables us to provide knowledge transfer at all levels: training,
coaching and staff supplementation. We provide a wide variety of services as well as approaches to agility.

Quality Training
Design Patterns Effective ASP.NET Use Cases On-Site Courses!
Lean Software Development
ScrumMaster Certification by Net Objectives Instructor Led / Web-
Based Training for
Test-Driven Development Languages
Extreme Programming, Effective Programming, RUP
_______________________________________________________________________________________________________________________________________________________________________________________________________________

"If I were tasked with bringing in an “Two things in life are certain: death and taxes” – Ben Franklin
outside design course, Net
Objectives’ would be on the top of my “In the information age, three things in life are certain – death,
list" - John Terrell, Microsoft taxes, and requirements will change” – Alan Shalloway
Lean Software Development and ScrumMaster Certification by Net Objectives
We offer training in both Lean Software Development and in Scrum. Our Lean Software Development training is based on Mary and Tom
Poppendieck’s work. Our Scrum training includes certification in being a ScrumMaster. We also provide training in how to be a Product
Champion (playing the role of the customer) in an agile project.
Agile Development Best Practices
In simple terms, an Agile Project is one that is predicated on making sure it is always doing the right thing, not merely following a plan that
has since gone out of date. The cornerstone of this approach is getting and adapting to feedback as the project progresses. Most projects
can't do this, so they fall further behind and either fail or provide inferior products. Changes are of many types, but the most common (and
important) changes are to the system's requirements. This course analyzes what it means to be an agile project, and provides a number of
best practices that provide and/or enhance agility. Different agile practices (including RUP, XP and Scrum) are discussed.
Agile Use Case Analysis
This 3-day course provides theory and practice in writing use cases, an understanding of how use cases fit into software development, and
the use of the “ever unfolding story” to incrementally refine the use cases into a robust requirements model. The course is largely based on
Alistair Cockburn's book "Writing Effective Use Cases" - winner of the Jolt Productivity Award for 2001. As a certified member of
Cockburn and Associates, we are one of the few companies authorized to teach it.
Design Patterns Explained: A New Perspective on Object-Oriented Design
This course goes beyond merely teaching several design patterns. It also teaches the principles and strategies that make design patterns
good designs. This enables students to use these advanced design techniques in their problems whether design patterns are even present.
After teaching several patterns and the principles underneath them, the course goes further by showing how patterns can work together to
create robust, flexible, maintainable designs.
Test-Driven Development
The practice of Agile Software Development requires, among other things, a high degree of flexibility in the coding process. As we get
feedback from clients, stakeholders, and end users, we want to be able to evolve our design and functionality to meet their needs and
expectations. This implies an incremental process, with frequent (almost constant) change to the code we're working on. Refactoring, the
discipline of changing code without harming it, is an essential technique to enable this process. Unit testing, which ensures that a given
change has not caused an unforeseen ripple effect in the system, is another.

Effective Object-Oriented Programming: Editions for Java, C++, C# and VB.NET

These courses take programmers who understand the syntax of the language but who aren’t taking advantage of object-oriented
development methods into the object-oriented world.
Get more info! Call Mike 275 118th Ave SE Ste. 115 [email protected]
Shalloway at 404-593-8375 Bellevue, WA 98005 www.netobjectives.com

© 2007 Net Objectives, Inc. All Rights Reserved 14