Unit 3

Organized Patterns Catalogue

 Organizing the Catalog
• Purpose – reflects what pattern does
– Creational – concern the process of object creation
– Structural – deal with the composition of classes or objects
– Behavioral – characterize the ways in which classes or objects interact
and distribute responsibility
• Scope – whether the pattern applies primarily to classes or to
objects
– Class – deal with relationships between classes and their subclasses –
inheritance – static – fixed at compile time
– Object – deal with object relationships – changed at runtime – more
dynamic
 Adapter Design Pattern
• Falls into Structural pattern
• Object adapter and Class adapter pattern
• Many times two classes are incompatible
because of incompatible interfaces
• Adapter pattern helps us to wrap a class
around the existing class and make the classes
compatible with each other.
• Match interfaces of different classes.
Adapter - definition
Adapter Structure
Adapter
Incompatible
Compatible - Object Adapter
Compatible - Class Adapter
 Bridge
• Structural
• Separates an object’s interface from its
implementation

Definition:
Bridge
Bridge
Bridge
Bridge – Abstraction part
Bridge – Implementation part
Bridge – Pattern Structure
 Composite
• A tree structure of simple and composite
objects.
• Allows to treat the different objects in similar
fashion.
 Composite (Structural)
• Intent
– Treat individual objects and multiple, recursively-
composed objects uniformly
• Applicability
– Objects must be composed recursively,
– And there should be no distinction between individual and
composed elements,
– And objects in the structure can be treated uniformly
– Part-Whole hierarchy of objects.
– Constant handling of objects as groups or individuals
 Composite (Cont'd)
• Known Uses
– ET++ VObjects
– InterViews Glyphs, Styles
© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

– Unidraw Components, MacroCommands

 Composite (Cont'd)
• Structure Component
*
+operation()
+add(in c : Component)
-children
+remove(in c : Component)
+getChild(in i : int)
© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

Leaf Composite

+operation() +operation()
+add(in c : Composite)
1
+remove(in c : Composite)
+getChild(in i : int)

{ forall g in children
g.operation(); }
Composite
Composite
Composite
Composite
Composite - Example
 Composite (Cont'd)
• Consequences
+ Uniformity: treat components the same regardless of
complexity
+ Extensibility: new Component subclasses work wherever
old ones do
– Overhead: might need prohibitive numbers of objects
• Implementation
– Do Components know their parents?
– Uniform interface for both leaves and composites?
– Don't allocate storage for children in Component base
class
– Responsibility for deleting children
 Decorator (Structural)
• Intent
– Adding objects with new responsibilities
– Add responsibilities to objects dynamically
© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

• Applicability
– When extension by subclassing is impractical
– For responsibilities that can be withdrawn
• Definition
 Decorator Diagram
• Structure

Component (Glyph) 1
© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

+operation() -component

ConcreteComponent Decorator (MonoGlyph)

{ component-> component.operation(); }
+operation() +operation() 1

ConcreteDecoratorB
ConcreteDecoratorA { super.operation();
-addedState addedBehavior(); }
+operation()
+operation()
+addedBehavior()
Decorator - Diagram
Decorator
 Decorator Overview
• A Decorator, also known as a Wrapper, is an object that has an interface
identical to an object that it contains. Any calls that the decorator gets, it
relays to the object that it contains, and adds its own functionality along
the way, either before or after the call.

• Therefore, the Decorator Pattern is used for adding additional

functionality to a particular object as opposed to a class of objects.

• It is easy to add functionality to an entire class of objects by subclassing an

object, but it is impossible to extend a single object this way. With the
Decorator Pattern, you can add functionality to a single object and leave
others like it unmodified.
 Decorator Comments
• The Decorator pattern gives you a lot of flexibility, since
you can change what the decorator does at runtime, as
opposed to having the change be static and determined at
compile time by subclassing.

• Since a Decorator complies with the interface that the

object that it contains, the Decorator is indistinguishable
from the object that it contains. That is, a Decorator is a
concrete instance of the abstract class, and thus is
indistinguishable from any other concrete instance,
including other decorators.

• This can be used to great advantage, as you can

recursively nest decorators without any other objects
being able to tell the difference, allowing a near infinite
amount of customization.
 Decorator (Cont'd)
• Consequences
+ Responsibilities can be added/removed at run-time
+ Avoids subclass explosion
+ Recursive nesting allows multiple responsibilities
© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

– Interface occlusion
– Identity crisis
• Implementation
– Interface conformance
– Use a lightweight, abstract base class for Decorator
– Heavyweight base classes make Strategy more attractive
 Decorator (Cont'd)
• Known Uses
– Embellishment objects from most OO-GUI toolkits
– ParcPlace PassivityWrapper
© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

– InterViews DebuggingGlyph
 Facade
• A single class that represents an entire
subsystem
Definition
Facade
Facade
© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

Façade

Façade
Façade
Façade
Façade
Façade
Façade - Example
 Facade Overview
• Example: WYSIWYG Editor (Cont'd)
– Spelling checking & hyphenation
• Iterator
• Visitor
• Some more patterns
– Template Method
– Singleton
– Façade
• Observations and Conclusions
• Further reading
 Flyweight pattern
• A fine-grained instance used for efficient
sharing
• Where we need to create many objects and all
these objects share some kind of common
data.
Flyweight pattern
Flyweight pattern
Flyweight pattern
Flyweight pattern
 Proxy
• An object representing another object.
• A well-known example of the proxy pattern is
a reference counting pointer object.
Definition
Proxy