Chapter 4

Simple Patterns for Extensibility





Literature (To Be Read)

 On Composite, Visitor: T. Panas. Design Patterns, A Quick Introduction. Paper in

Design Pattern seminar, IDA, 2001. See home page of course.
 Gamma: Composite, Decorator, ChainOfResponsibility, Bridge, Visitor, Observer,
Proxy
 J. Smith, D. Stotts. Elemental Design Patterns. A Link Between Architecture and Object
Semantics. March 2002. TR02-011, Dpt. Of Computer Science, Univ. of North Carolina
at Chapel Hill
http://www.cs.unc.edu/techreports/02-011.pdf

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 2
Design Patterns and Frameworks // 30.10.2018
Optional Literature

 Marko Rosenmüller. Towards Flexible Feature Composition: Static and Dynamic

Binding in Software Product Lines. PhD thesis, Fakultät für Informatik, Otto-von-
Guericke-Universität Magdeburg, June 2011.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.220.8672
 Marko Rosenmüller, Norbert Siegmund, Sven Apel, and Gunter Saake. Flexible
Feature Binding in Software Product Lines. Automated Software Engineering,
18(2):163-197, June 2011.
http://wwwiti.cs.uni-magdeburg.de/iti_db/publikationen/ps/auto/RSAS11.pdf

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 3
Design Patterns and Frameworks // 30.10.2018
Goal

 Understanding extensibility patterns

 ObjectRecursion vs TemplateMethod, Objectifier (and Strategy)
 Decorator vs Proxy vs Composite vs ChainOfResponsibility

 Parallel class hierarchies as implementation of facets

 Bridge
 Visitor
 Observer (EventBridge)

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 4
Design Patterns and Frameworks // 30.10.2018
Static and Dynamic Extensibility

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 5
Design Patterns and Frameworks // 30.10.2018
Variability vs Extensibility

 Variability so far meant

 Static extensibility, e.g., new subclasses
 Often, dynamic exchangability (polymorphism)
 But not dynamic extensibility

 Now, we will turn to patterns that allow for dynamic extensibility

 Most of these patterns contain a 1:n-aggregation that is extended at runtime

Binding a hook with

a hook value Extending a hook with
another hook value
Chapter 4 – Extensibility Patterns
Software Technology Group / Dr. Sebastian Götz Folie 6
Design Patterns and Frameworks // 30.10.2018
3.1 Recursive Extension

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 7
Design Patterns and Frameworks // 30.10.2018
3.1.1 Object Recursion Pattern

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 8
Design Patterns and Frameworks // 30.10.2018
Object Recursion

 Similar to TemplateMethod, Objectifier and Strategy

 But now, we allow for recursion in the dependencies between the classes (going via
inheritance and aggregation)
 The aggregation can be 1:1 (lists, 1-Recursion) or 1:* (trees, n-recursion), *:* (DAGs or
graphs, n-recursion)
1 or +
Client Handler
childObject(s)
handleRequest()
preHandleRequest(Component)
postHandleRequest(Component)

1 or +
Terminator Recurser
preHandleRequest()
handleRequest() handleRequest() for all g in childObject(s)
preHandleRequest(Component)
Chapter 4 – Extensibility Patterns g.handleRequest()
Software Technology Group / Dr. Sebastian Götz Folie 9
postHandleRequest(Component)
Design Patterns and Frameworks // 30.10.2018 postHandleRequest()
Incentive

 ObjectRecursion is a simple (sub)pattern

 in which an abstract superclass specifies common conditions for two kinds of
subclasses, the Terminator and the Recurser (a simple contract)
 Since both fulfill the common condition, they can be treated uniformly under one
interface of the abstract superclass

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 10
Design Patterns and Frameworks // 30.10.2018
Object Recursion – Runtime Structure

1-ObjectRecursion creates lists n-ObjectRecursion creates trees, DAGs,

and graphs

:Cons :Cons

:Cons

:Cons :Cons

:Cons

:Nil :Nil

The recursion allows for building up runtime nets :Nil

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 11
Design Patterns and Frameworks // 30.10.2018
3.1.2 Composite

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 12
Design Patterns and Frameworks // 30.10.2018
Structure Composite

Component *
Client
childObjects
commonOperation()
preHandleRequest(Component)

}
postHandleRequest(Component)
add(Component)
remove(Component)
Pseudo implementations

Leaf Composite
commonOperation() commonOperation() for all g in childObjects
add(Component) g.commonOperation()
remove(Component)
getType(int)

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 13
Design Patterns and Frameworks // 30.10.2018
Piece Lists in Production Data

abstract class CarPart { class Screw extends CarPart {

int myCost; int myCost = 10;
abstract int calculateCost(); int calculateCost() {
} return myCost;
}
class ComposedCarPart extends CarPart {
}
int myCost = 5;
// here is the n-recursion
CarPart [] children; // application
int calculateCost() { int cost = carPart.calculateCost();
for (i = 0; i <= children.length; i++)
{
curCost +=
children[i].calculateCost();
}
return curCost + myCost;
}
void addPart(CarPart c) {
children[children.length++] = c;
}
}

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 14
Design Patterns and Frameworks // 30.10.2018
Purpose

 The Composite is older as ObjectRecursion, from GOF

 ObjectRecursion is a little more abstract

 As in ObjectRecursion, an abstract superclass specifies a contract for two

kinds of subclasses
 Since both fulfill the common condition, they can be treated uniformly under one
interface of the abstract superclass

 Good method for building up trees and iterating over them

 The iterator does not need to know whether it works on a leaf or an inner node.
It can treat all nodes uniformly for
 Iterator algorithms (map)

 Folding algorithms (folding a tree with a scalar function)

 The Composite's secret is whether a leaf or inner node is worked on

 The Composite's secret is which subclass is worked on

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 15
Design Patterns and Frameworks // 30.10.2018
 Composite Run-Time Structure

Part/Whole hierarchies, e.g., nested graphical objects

:Picture

:Picture :Line :Rectangle

:Picture :Line :Rectangle

common operations: draw(), move(), delete(), scale()

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 16
Design Patterns and Frameworks // 30.10.2018
Dynamic, Recursive Extensibility of Composite

 Due to the n-recursion, new children can always be added into a composite node
 Whenever you have to program an extensible part of a framework, consider
Composite

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 17
Design Patterns and Frameworks // 30.10.2018
Relations of Composite to Other Programming
Domains

 Composite pattern is the heart of functional programming

 Because recursion is the heart of functional programming
 It has discovered many interesting algorithmic schemes for the
Composite:
 Functional skeletons (map, fold, partition, d&c, zip...)

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 18
Design Patterns and Frameworks // 30.10.2018
3.1.3 Decorator

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 19
Design Patterns and Frameworks // 30.10.2018
Decorator Pattern

 A Decorator is a skin (wrappers) of another object

 Core objects are at the end of a decorator chain

 It is a 1-ObjectRecursion (i.e., a restricted Composite):

 A subclass of a class that contains an object of the class as child
 However, only one composite (i.e., a delegatee)
 Combines inheritance with aggregation

 Similar to ObjectRecursion and Composite, inheritance from an abstract

Handler class
 That defines a contract for the mimiced and the mimicing class

:Client
A:Decorator
B:Decorator RealObject:
ref ConcreteMimiced
hidden Class
hidden

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 20
Design Patterns and Frameworks // 30.10.2018
Decorator – Structure Diagram
1
MimicedClass
mimiced
mimicedOperation()

ConcreteMimicedClass Decorator

mimicedOperation()
mimicedOperation()
preAction()
postAction() preAction();
mimiced.mimicedOperation();
postAction();

ConcreteDecoratorA ConcreteDecoratorB
super.mimicedOperation();
mimicedOperation() mimicedOperation() additionalStuff():

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 21
Design Patterns and Frameworks // 30.10.2018
Decorator for Widgets

1
Widget

mimiced
draw()

TextWidget WidgetDecorator

draw() draw()

mimiced.draw()

Frame Scrollbar
super.draw();
super.draw(); draw() draw() drawScrollbar():
drawFrame():

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 22
Design Patterns and Frameworks // 30.10.2018
 Decorator for Persistent Objects

1
Record

access() mimiced

TransientRecord PersistentDecorator

access() access()
mimiced.access()

PersistentRead PersistentRecord
OnlyRecord if (!loaded()) load();
access() super.access();
if (!loaded()) load(); access()
boolean loaded() if (modified()) dump():
super.access(); boolean loaded()
boolean modified()
load()
load()
dump()

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 23
Design Patterns and Frameworks // 30.10.2018
 Purpose Decorator

 For extensible objects (i.e., decorating objects)

 Extension of new features at runtime
 Removal possible

 Instead of putting the extension into the inheritance hierarchy

 If that would become too complex
 If that is not possible since it is hidden in a library

Library Library

New Features
Decorator with
New Features

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 24
Design Patterns and Frameworks // 30.10.2018
3.1.4 Chain of Responsibility

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 25
Design Patterns and Frameworks // 30.10.2018
Chain of Responsibility

 Delegate an action to a list of delegatees that attempt to solve the problem one
after the other
 They delegate further on, down the chain
 No core object

ObjectStructure:

:Client
A:ConcreteWorker
aWorker B:ConcreteWorker
successor ...
successor

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 26
Design Patterns and Frameworks // 30.10.2018
 Structure for ChainOfResponsibility

 A Chain is recursing on the abstract super class, i.e.,

 All classes in the inheritance tree know they hide some other class (unlike the
ObjectRecursion)

Successor
1
Client Worker

Work()

ConcreteWorker1 ConcreteWorker2

Work() Work()

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 27
Design Patterns and Frameworks // 30.10.2018
Chains in Runtime Trees

 Chains can also be parts of a tree

 Then, a chain is the path upward to the root of the tree

Text:Widget

:Frame :Frame :Frame

:Scrollbar :Scrollbar :Scrollbar

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 28
Design Patterns and Frameworks // 30.10.2018
 Example ChainOfResponsibility: Help System for a GUI

nextWorker ObjectStructure is a Tree of Help

HelpWorker
Functions:
WorkOnHelpQuery()

:PrintButton :OKButton

Application Widget nextWorker nextWorker

:PrintDialog :StoreDialog
Dialog Button
nextWorker nextWorker
WorkOnHelpQuery()
showHelp()

StoreDialog PrintDialog :Application

nextWorker
OKButton PrintButton

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 29
Design Patterns and Frameworks // 30.10.2018
Help System with Chain

abstract class HelpWorker { class Button extends Widget {

// here is the 1-recursion bool haveHelpQuery;
HelpWorker nextWorker; void workOnHelpQuery() {
void workOnHelpQuery() { if (haveHelpQuery) {
if (nextWorker != null) help();
nextWorker.workOnHelpQuery(); } else {
} super.workOnHelpQuery();
class Widget extends HelpWorker { }
// this class can contain fixing code }
} }
class Dialog extends Widget {
void workOnHelpQuery() { // application
help(); button.workOnHelpQuery();
super.workOnHelpQuery(); // may end in the inheritance
} hierarchy up in Widget, HelpWorker
} // dynamically in application object
class Application extends HelpWorker
{ ....}

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 30
Design Patterns and Frameworks // 30.10.2018
ChainOfResponsibility - Applications

 Realizes Dynamic Call:

 If the receiver of a message is neither known at compile-time nor at
allocation time (polymorphism), but only at runtime (i.e., depends on the
current net of objects)
 Dynamic call is the key construct for service-oriented architectures (SOA)
 Dynamic extensibility: if new receivers with new behavior should be
added at runtime
 Unforeseen dynamic extensions
 However, no mimiced object as in Decorator
 Anonymous communication
 If identity of receiver is unknown or not important
 If several receivers should work on a message

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 31
Design Patterns and Frameworks // 30.10.2018
Composite vs Decorator vs Chain

Decorator

but also different features

Common contract 1:1 successor relation

ObjectRecursion runtime list

1:n successor relation

runtime tree/
Composite graph

All methods in common

Chain

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 32
Design Patterns and Frameworks // 30.10.2018
3.2. Flat Extensibility
3.2.1 Proxy

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 33
Design Patterns and Frameworks // 30.10.2018
 Proxy

Hide the access to a real subject by a representative

Client Subject

operation()

realSubject
RealSubject Proxy
...
operation() operation()
realSubject.operation()

Object Structure:
:Client
A:Proxy B:RealSubject

ref
realSubject successor

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 34
Design Patterns and Frameworks // 30.10.2018
Proxy

 The proxy object is a representative of an object

 The Proxy is similar to Decorator, but it is not derived from ObjectRecursion
 It extends flat: It has a direct pointer to the sister class, not to the superclass
 It may collect all references to the represented object (shadows it). Then, it is a
facade object to the represented object
 Consequence: chained proxies are not possible, a proxy is one-and-only
 Clear difference to ChainOfResponsibility
 Decorator lies between Proxy and Chain.

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 35
Design Patterns and Frameworks // 30.10.2018
Proxy Variants

 Filter proxy (smart reference): executes additional actions, when the object is
accessed
 Protocol proxy: counts references (reference-counting garbage collection
 or implements a synchronization protocol (e.g., reader/writer protocols)
 Indirection proxy (facade proxy): assembles all references to an object to
make it replaceable
 Virtual proxy: creates expensive objects on demand
 Remote proxy: representative of a remote object
 Caching proxy: caches values which had been loaded from the subject
 Remote
 Loading lazy on demand
 Protection proxy
 Firewall

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 36
Design Patterns and Frameworks // 30.10.2018
Proxy – Other Implementations

 Overloading of “->” access operation

 C++, Ada and other languages allow for overloading access
 Then, a proxy can intervene, but is invisible

 Overloading access can be built in into the language

 There are languages that offer proxy objects
 Modula-3 offers SmartPointers
 Gilgul offers proxy objects

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 37
Design Patterns and Frameworks // 30.10.2018
Proxy vs Decorator vs Chain

Decorator

n sucessors possible
Shadowing
runtime list
1:1 successor relation,
1:1 successor relation
1 successor Instance of ObjectRecursion
Methods in common
Aggregation to
sister class

Proxy

Chain

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 38
Design Patterns and Frameworks // 30.10.2018
3.2.2 Star-Bridge (*-Bridge)

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 39
Design Patterns and Frameworks // 30.10.2018
 Extensibility Pattern
*DimensionalClassHierarchies (*Bridge)
Template Hook
hookObjects
TemplateClass HookClass
templateMethod() *
add(hookObj) hookMethod()
remove(Obj)
foreach h in hookObjects
h.hookMethod()

Concrete
MoreConcrete MoreConcrete Concrete
HookClassB
TemplateA TemplateB HookClassA
hookMethod()
templateMethod() templateMethod() hookMethod()

// Implementation A
foreach h in hookObjects
h.hookMethod();
// Implementation B
foreach h in hookObjects
h.hookMethod();

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 40
Design Patterns and Frameworks // 30.10.2018
3.2.3 Observer (Event Bridge)

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 41
Design Patterns and Frameworks // 30.10.2018
Observer (Publisher/Subscriber, Event Bridge)
Observer

Window Window Window

a b c
x 60 30 10
y 50 30 20
z 80 10 10
a b c

a=50% Notify on change

b=30%
c=20%
Queries

Subject

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 42
Design Patterns and Frameworks // 30.10.2018
Structure Observer

*
Subject Observer
observers
register(Observer) update ()
unregister(Observer)
for all b in observers {
notify()
b.update ()
}

ConcreteObserver
Subject ObserverState =
ConcreteSubject update () Subject.getState()

getState() ObserverState
setState()

SubjectState Difference to Star-Bridge: hierarchies are

return SubjectState
not completely independent;
Observer knows about Subject
Chapter 4 – Extensibility Patterns
Software Technology Group / Dr. Sebastian Götz Folie 43
Design Patterns and Frameworks // 30.10.2018
Sequence Diagram Observer

 Update() does not aSubject anObserver anotherObserver

transfer data, only an register()
event (anonymous
communication register()

possible) setState()
notify()
 Observer pulls data out
itself
update 1()
 Due to pull of data,
subject does not care getState()
nor know, which update n()
observers are involved:
subject independent of getState()
observer

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 44
Design Patterns and Frameworks // 30.10.2018
 Observer Variants

 Multiple subjects:
 If there is more than one subject,
send Subject as Parameter of update(Subject s).
 Push model: subject sends data in notify()
 The default is the pull model: observer fetches data itself

 Change manager

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 45
Design Patterns and Frameworks // 30.10.2018
Structure Data-Pushing-Observer

*
Subject PushObserver
observers
update(Data)
register(PushCallBack) // push(Data)
unregister(PushCallBack
Back) for all b in observers {
notify(d:Data)
b.update (d)
}

Concrete
PushObserver
ConcreteSubject update (Data) do something with Data

ObserverState

d:Data no permanent back link;

instead data is pushed

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 46
Design Patterns and Frameworks // 30.10.2018
Sequence Diagram Data-Push-Observer

 Update() transfers Data to Observer (push)

:aConcreteSubject :aConcreteObserver :anotherConcreteObserver

register()
setState()
notify()

update 1(d:Data)
...
update n(d:Data)

...

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 47
Design Patterns and Frameworks // 30.10.2018
Observer - Applications

 Loose coupling in communication

 Observers decide what happens
 Dynamic change of communication
 Anonymous communication
 Multi-cast and broadcast communication
 Cascading communication if observers are chained (stacked)

 Communication of core and observing aspect

 Observers are a simple way to implement aspect-orientation by hand
 If an abstraction has two aspects and one of them depends on the other, the
observer can implement the aspect that listens and reacts on the core

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 48
Design Patterns and Frameworks // 30.10.2018
Observer with ChangeManager (Mediator)

Subject * ChangeManager * Observer

Subjects Observer
register(Subject,Observer) update (Subject)
register(Observer)
unregister(Subject,Observer)
unregister(Observer)
notify() manager notify()
Subject-Observer-mapping

manager.notify()
SimpleChangeManager DAGChangeManager
register(Subject,Observer) register(Subject,Observer)
manager.register(this,b) unregister(Subject,Observer) unregister(Subject,Observer)
notify() notify()

for all s in Subjects

for all b in s.Observer mark all observers to be updated
b.update (s) update all marked observers

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 49
Design Patterns and Frameworks // 30.10.2018
ChangeManager is also Called Eventbus

Basis of many interactive application frameworks (Xwindows, Java AWT, Java InfoBus, ....)

Subject Subject Subject

EventBus (Mediator)

Observer Observer Observer

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 50
Design Patterns and Frameworks // 30.10.2018
 Relations Extensibility Patterns
Unconstrained Patterns Proxy Visitor

Decorator
Bridge *-Bridge

ObjectRecursion Chain
Observer
unconstraining
Composite

unconstraining Dimensional
ClassHierarchies

Recursive Framework Patterns Connection

T&H Pattern obeying T&H role T&H Pattern
model
Chapter 4 – Extensibility Patterns
Software Technology Group / Dr. Sebastian Götz Folie 51
Design Patterns and Frameworks // 30.10.2018
Summary

 Most often, extensibility patterns rely on ObjectRecursion

 An aggregation to the superclass

 This allows for constructing runtime nets: lists, sets, and graphs
 And hence, for dynamic extension
 The common superclass ensures a common contract of all objects in the
runtime net

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 52
Design Patterns and Frameworks // 30.10.2018
The End

Chapter 4 – Extensibility Patterns

Software Technology Group / Dr. Sebastian Götz Folie 53
Design Patterns and Frameworks // 30.10.2018