13.

Frameworks and Patterns -

Framework Extension Patterns

1) Extension Object Pattern

Prof. Dr. U. Aßmann
Software Engineering Group 2) Large Layered Frameworks
Department of Computer Science 3) Role Object Pattern
Technische Universität Dresden 4) GenVoca Pattern
5) Mixin Layer Pattern
Version WS17/18 - Jan 15, 2018

Lecturer: Dr. Sebastian Götz

Design Patterns and Frameworks, © Prof. Uwe Aßmann

 Literature (To Be Read)

2
► E. Gamma. The Extension Objects Pattern. Conf. On Pattern Languages of
Programming (PLOP) 97, ACM. http://portal.acm.org/citation.cfm?id=273448.273455
► Y. Smaragdakis and D. Batory. Mixin layers: an object-oriented implementation
technique for refinements and collaboration-based designs. ACM Transactions
on Software Engineering and Methodology, 11(2):215–255, 2002.
http://dl.acm.org/citation.cfm?id=505148
Prof. Uwe Aßmann, Design Patterns and Frameworks

► D. Bäumer, D. Riehle, W. Silberski, M. Wulf. Role Object. Conf. On Pattern

Languages of Programming (PLOP) 97.
http://hillside.net/plop/plop97/Proceedings/riehle.pdf
► D. Riehle, T. Gross. Role Model Based Framework Design and Integration. Proc.
1998 Conf. On Object-oriented Programing Systems, Languages, and Applications
(OOPSLA 98) ACM Press, 1998.
http://dl.acm.org/citation.cfm?id=286951
► D. Bäumer, G. Gryczan, C. Lilienthal, D. Riehle, H. Züllighoven. Framework
Development for Large Systems. Communications of the ACM 40(10), Oct. 1997.
http://dl.acm.org/citation.cfm?id=262804
 Further Literature

3
► D. Bäumer. Softwarearchitekturen für die rahmenwerkbasierte Konstruktion grosser
Anwendungssysteme. PhD thesis, 1997, Universität Hamburg.
► JWAM sites
– http://www.c1-wps.de/forschung-und-lehre/fachpublikationen/

– www.jwam.de
– http://sourceforge.net/projects/jwamtoolconstr/
Prof. Uwe Aßmann, Design Patterns and Frameworks

► U. Aßmann. Composing Frameworks and Components for Families of Semantic Web

Applications. Lecture Notes In Computer Science, vol. 2901, Nov. 2003.
► U. Aßmann, J. Johannes, J. Henriksson, and I. Savga. Composition of rule sets and
ontologies. In F. Bry, editor, Reasoning Web, Second Int. Summer School 2006,
number 4126 in LNCS, pages 68-92, Sept 2006. Springer.

► Y. Smaragdakis, D. Batory. Implementing layered designs with mixin layers. In

Lecture Notes in Computer Science (LNCS) 1998, Springer-Verlag.
 Goal

4 ► Studying extensible framework hook patterns

– Understand patterns:
● Extension Object,
● Role Object, and
● Genvoca
See how layered frameworks can be implemented by
Prof. Uwe Aßmann, Design Patterns and Frameworks

–
● Role Object and
● Genvoca
► Understand these patterns as extension points of frameworks,
i.e., framework hook patterns
 Frameworks Must Be Extensible

5 ► Frameworks must evolve, be adapted

► Idea: instead of variability hooks, use extensibility hooks
– based on basic extensibility patterns
► Presented in this lecture:
– Gamma's Extension Object Pattern (EOP)
Prof. Uwe Aßmann, Design Patterns and Frameworks

– Layered frameworks
● Riehle/Züllighoven's RoleObject pattern (ROP)
● Batory's mixin layer pattern (GenVoca pattern)
 13.1 The ExtensionObjects
Pattern (EOP)
6

Extensions of Objects, visible for the Client

Design Patterns and Frameworks, © Prof. Uwe Aßmann

 Structure of ExtensionObjects

7
► Whenever a complex object has non-mandatory parts that can be added, if necessary
► Extension is the base class of all extensions
► AbstractExtension defines an interface for a concrete hierarchy of extension objects
► Extensions can be added, retrieved, and removed by clients

Client
Prof. Uwe Aßmann, Design Patterns and Frameworks

Subject

getExtension(name) owner
Extension
addExtension(name, Extension)
removeExtension(name)

ConcreteSubject 1 or n

getExtension(name) AbstractExtension AbstractExtension

extension
addExtension(name, Extension)
removeExtension(name)

Concrete Concrete Concrete

Extension1 Extension2 Extension3
 Example: Spellcheckers in Document
Models
8 ► E.g., OpenDoc or OLE documents
Client

<<template>>
Document

owner <<hook>>
getExtension(name)
Extension
addExtension(name, Extension)
Prof. Uwe Aßmann, Design Patterns and Frameworks

removeExtension(name)

ConcreteDocument 1 or n
Spellchecker WordCounter
getExtension(name) extension
addExtension(name, Extension)
removeExtension(name)

French English German

Spellchecker Spellchecker Spellchecker
 Discussion of EOP

9 ► If there is 1 extension object, naming is not necessary

► If there are n extension objects, a dictionary (map) has to map names to
extension objects
► Advantages
– Complex objects can be split into simpler parts
– Extensions can model (optional) roles of objects
Prof. Uwe Aßmann, Design Patterns and Frameworks

– Extensions can be added dynamically and unforeseen

► Disadvantage
– Clients have to manage extension objects themselves, and hence, are more
complex
– Extension objects suffer from the object schizophrenia problem: the logical this
of an extension object is the subject, but the physical this is the extension object
► Relations to Other Patterns
– If many objects of an application have the same roles that are realized by
extension objects, ExtensionObjects can be generalized to the Role Object
Pattern
 ExtensionObjects at Framework Borders

10 ► Since with EOP, clients have to manage extensions themselves,

the use of the template object in the framework does not help to
use the hook objects
Framework Client

<<template>>
Subject
Prof. Uwe Aßmann, Design Patterns and Frameworks

owner <<hook>>
getExtension(name)
Extension
addExtension(name, Extension)
removeExtension(name)

ConcreteSubject 1 or n
AbstractExtension1 AbstractExtension2
getExtension(name) extension
addExtension(name, Extension)
removeExtension(name)

Concrete Concrete Concrete

Extension1 Extension2 Extension3
 EOP as Framework Hook Pattern

11 ► Since the hook object is not mandatory, also 1-H=T is a real

extensibility pattern for frameworks

1-H=T n-H=T
T has 1 H part T has n H parts
T owns H T owns H parts
Prof. Uwe Aßmann, Design Patterns and Frameworks

T 1 H T n H

T= H T = *H
 Optional Tools for Documents in an Office
Framework
12

Office Framework
Prof. Uwe Aßmann, Design Patterns and Frameworks

Document
=
* SpellChecker

WordCount

a.s.o
 13.2 Extensibility of Frameworks
with Layers
13

... with Layered Role Object Frameworks

Design Patterns and Frameworks, © Prof. Uwe Aßmann

 Case Study GEBOS

14 ► GEBOS is a banking application for RWG banking group with 450

banks, south of Germany
– Banking applications, with services: tellers, loans, stocks, investment,
self-service
– 2500 C++ classes, arranged in frameworks, Arranged in layers
► Concepts of the bank application domain
Prof. Uwe Aßmann, Design Patterns and Frameworks

– Banks organize themselves in business sections (tellers, loans, etc.)

● Department of specialists that have a certain expertise
– Workplace contexts
● Service centers offer customers an all-in-one service
● Services of the business sections
● Every workplace needs different application systems
– Business domain
● Business objects such as bill, order, account
 Application Framework Layers

15 ► GEBOS demonstrates that it is advantageous to structure an

application framework into layers
– Application layers, Business Section layers, Business domain layers
– Desktop Layer, Technical kernel layer

Technical Application Layers Desktop

Kernel Layer
Prof. Uwe Aßmann, Design Patterns and Frameworks

Layer Adviser Telephone

Teller ...
Desktop Banking
Tool
Graphic
Interface Business Section Layers
Folders
Teller Loans Investment ...
Collections

Business Domain Layer Values

Account Loan Product ... ...

 Layers

16 ► Technical Kernel Layer

– Service layer, independent of other layers
– Domain independent, application independent
– Is a framework itself
● Collections, Middleware, Wrappers
Garbage collection, late creation, factories, trace support
Prof. Uwe Aßmann, Design Patterns and Frameworks

– Is a blackbox framework
► Desktop Layer
– Support for interactive workplaces
– Contains a tool construction framework (for the Tools&Materials
approach)
– MVC framework, Folder framework, Value framework for business and
domain values
● AccountNumber, ClientNumber, Money etc
– Look and feel, reusable for office domains with GUI applications
 Layers

17 ► Business Domain Layer contains the business core concepts:

Account, customer, product, value types
– Shares knowledge for all business sections
– Think about how to divide the knowledge between business domain
layer and business section layers
► Business Section Layers
Prof. Uwe Aßmann, Design Patterns and Frameworks

– Subclassing business domain and desktop layers, “inherits” knowledge

from both
– Business section concepts: Borrower, investor, guarantor, loan, loan
account, tools. Organizational entities and notions
– Distinguish from business domain
► Application Layers
– Application concepts
– Separate from Business Sections, because workplaces need different
functionality from different business sections
– Uses (and inherits) from all other layers
 Goals in Framework Design of GEBOS

18 ► Minimize coupling between frameworks and application systems

– Frameworks should never be touched when developing an
application system
► Model different facets of business sections, products, and
business domain concepts
Prof. Uwe Aßmann, Design Patterns and Frameworks

– Use role-object design pattern

► Minimize coupling between the layers
– Separate concepts from implementation
– Move implementation to lower layers
► Achieved with the RoleObject pattern
 13.3 The RoleObject Pattern

19

Design Patterns and Frameworks, © Prof. Uwe Aßmann

 Framework Extensibility with Riehles Role-
Object Layers
20 ► The Role-Object Pattern (ROP) is both a variability and
extensibility pattern
– Realizes the “dispatch on all layers” for application frameworks
– Can easily be extended with new layers
► Extension of a core layer (a blackbox framework of core
Prof. Uwe Aßmann, Design Patterns and Frameworks

objects) with layers of delegatees (role objects)

– A conceptual object (complex object, subject) of the
application is split over all layers
– Core and role objects conceptually belong together to the
conceptual object, but distribute over the layers
– Role objects are views on the conceptual object
 Riehle/Züllighovens Role Object Pattern
(ROP)
21
Application Layers

Client static knowledge

potential run-time
Business Section Layers access
Prof. Uwe Aßmann, Design Patterns and Frameworks

Borrower Guarantor Investor

Business Domain Layer

Customer

CustomerCore * CustomerRole
 Role Object Pattern with Inheritance Drawn
Upwards
22 Business Domain Layer <<interfaces>>
<<template classes>>
Customer

CustomerCore * CustomerRole
Prof. Uwe Aßmann, Design Patterns and Frameworks

<<static>>

Business Section Layers

Borrower Guarantor Investor

<<dynamic>>
<<implementations>>
Application Layer

Client
 Riehle/Züllighovens Role Object Pattern
Abstracted (“Deep Roles”)
23 Core Layer 1
Application <<interfaces>>
Conceptual
Client

Core * Role
Prof. Uwe Aßmann, Design Patterns and Frameworks

Layer 2

Role1 Role2 Role3

<<implementations>>

Layer 3

Role1 Role2 Role3

<<implementations>>
 Riehle/Züllighovens Role Object Pattern
Variant 2 (“Flat Roles”)
24 ► Variant 2 has no Decorator; roles only know cores

Application Core Layer 1 <<interfaces>>

Conceptual
Client
Prof. Uwe Aßmann, Design Patterns and Frameworks

Core Role
*
Layer 2

Role1 Role2 Role3

<<implementations>>

Layer 3

Role1 Role2 Role3

<<implementations>>
 Run-time Behavior of ROP

25 ► Change of role:
– Different Role Objects may belong to the same role type (e.g.,
working for multiple companies)
– Over time, the role object for a player may change
– This expresses states of the player in the application
Prof. Uwe Aßmann, Design Patterns and Frameworks

● E.g., Borrrower --> UnsafeBorrower --> TrustedBorrower

► Roles are created on-demand
– In the beginning, the Subject is slim, i.e., carries no roles.
– At service requests, the core creates roles and enters them in
the role map
 Variant 3: Core Layer with Traded Call

26 ► To add services dynamically (beyond the service interfaces in the

conceptual object), add a trader to the core
● A trader is a method that interprets a service request based on a service
description Core Layer 1 <<interfaces>>
Conceptual
addRole()
// enter traded role //
Prof. Uwe Aßmann, Design Patterns and Frameworks

addRole(ServiceDescription)
Interpret serviceDescription; removeRole()
add concrete role and service hasRole()
under service description giveRole()
in role map;
accept(ServiceDescription)
service1()

Role Map Core * Role

addRole() addRole()
removeRole() removeRole()
// Traded call // hasRole() hasRole()
Interpret serviceDescription; giveRole() giveRole()
Lookup concrete service
in role map; accept(ServiceDescription) accept(S.D.)
Call; service1() service1()
 RoleObjectPattern and Other Patterns

27 ► ROP is not only a Decorator

– It is based on 1-H<=T, i.e., 1-ObjectRecursion
● All role objects inherit from the abstractum
– Remember, 1-ObjectRecursion based patterns lend themselves to
extension
– And 1-H<=T framework hook patterns provide extensible frameworks
Prof. Uwe Aßmann, Design Patterns and Frameworks

– 1:n relationship between core and role objects

– Role objects decorate the core object, and pass requests on to it
 Comparison of Role Objects with
Inheritance
28 ► Simple inheritance has one instance of a subclass at a time
– Subclass can change over time (polymorphism)
► The role object has many of them at the same time
– All role objects can change (role polymorphism)
► Only changes in the base layers (technical, presentation,
Prof. Uwe Aßmann, Design Patterns and Frameworks

business) affect other layers

– Changes in the business section layers do not affect the business
domain layers
► The relation of core and role objects is a special form of part-of
(combined with inheritance)
 Role Object Pattern with Template and
Hook Stereotypes
29
Business Domain Layer
<<template class>> <<template class>>
Customer Account

<<template class>> <<hook class>> <<template class>> <<hook class>>

* CustomerRole
Prof. Uwe Aßmann, Design Patterns and Frameworks

CustomerCore AccountCore * AccountRole

Business Section Investment Layer

Investor Savings
Account

Business Section Loan Layer

Borrower Loan
Account
 Role Object Pattern and Role Models on
Role Layers
30 ► Usually, roles of one subject talk to other roles of another subject on the
same layer (within a role model)
► Cores never talk to each other directly
Business Domain Layer

Customer Account
Prof. Uwe Aßmann, Design Patterns and Frameworks

CustomerCore * CustomerRole AccountCore * AccountRole

Business Section Investment Layer

Savings
Investor
Account

Business Section Loan Layer

Borrower Loan
Account
 Switching Variable Role Layers

31 ► At run time, entire role models on role layers can be exchanged

(variable role layers)

Business Domain Layer

Customer Account
Prof. Uwe Aßmann, Design Patterns and Frameworks

CustomerCore * CustomerRole AccountCore * AccountRole

Business Section Investment Layer

Garantee
Garantor
Contract

Business Section Loan Layer

Borrower Loan
Account
 Riehle/Züllighovens Layer Pattern As
Framework Hook Pattern
32

Role n-TrH H
T2 has H parts
n n
Conceptual T1
H and T2 inherit
from T1
Core T2
Prof. Uwe Aßmann, Design Patterns and Frameworks

H knows T1

Core-Role-Pattern
n-TrH mini-connector

Con R

C R C n R

R
 ROP Ensures Extensibility

33 ► The ROP lends itself not only to variability, but also to dynamic
extensibility
– If a framework hook is a role object pattern, the hook can be
extended in unforeseen ways without changing the framework!
– New layers of the application or the framework can be added at
design time or runtime
Prof. Uwe Aßmann, Design Patterns and Frameworks

► Powerful extension concept with ROP-Trader

– Whenever you have to design something complex which should
be extensible in unforeseen ways, consider Role Object
 Riehle/Züllighovens Layered Role Object
Framework
34

Role Layer 1 Role Layer 2 Role Layer 3

Core Layer R
Prof. Uwe Aßmann, Design Patterns and Frameworks

C R

R
 13.4 The GenVoca Pattern, Mixin
Layers, and Layered Mixin
Frameworks
35

Design Patterns and Frameworks, © Prof. Uwe Aßmann

 The Mixin Concept

36
► A mixin is a partial class, for an extension of another class
► A mixin-base is a class with a generic super class, a mixin parameterizes this
► Some languages have mixins (Scala, C#, Eiffel); otherwise, mixins can be expressed as class
fragments that can be parameterized with a superclass (C++)
► Mixins can implement (static) roles and facets

Person
Prof. Uwe Aßmann, Design Patterns and Frameworks

template
template <class
<class S>
S>
class
class EmployeeMixin extends
EmployeeMixin extends SS {{ <<parameterize>>
//
// class
class extension..
extension..
Salary salary;
Salary salary;
Employer
Employer emp;
emp; EmployeeMixin
}}

EmployeeMixin<Person>
EmployeeMixin<Person> employeeOfPerson;
employeeOfPerson;
EmployeeMixin<German> employeeOfGerman;
EmployeeMixin<German> employeeOfGerman; EmployedPerson
EmployeeMixin<Club>
EmployeeMixin<Club> employeeOfClub;
employeeOfClub;
 The GenVoca Pattern

37 ► If several mixin parameterizations are nested, the GenVoca

pattern results [Batory]
template <class S> class EmployeeMixin extends S {
template <class S> class EmployeeMixin extends S {
Salary salary;
Salary salary;
Employer emp;
Employer emp; Person
}
}
Prof. Uwe Aßmann, Design Patterns and Frameworks

template <class S> class ParentMixin extends S {

template <class S> class ParentMixin extends S {
Child child;
Child child;
Money kindergeld;
Money kindergeld;
} EmployeeMixin
}
template <class S> class HobbyMixin extends S {
template <class S> class HobbyMixin extends S {
Hobby hobby;
Hobby hobby;
}
}
// Persons composed with GenVoca pattern ParentMixin
// Persons composed with GenVoca pattern
HobbyMixin<ParentMixin<EmployeeMixin<Person>>>> assmann;
HobbyMixin<ParentMixin<EmployeeMixin<Person>>>> assmann;
EmployeeMixin<ParentMixin<HobbyMixin<Person>>>> assmann2;
EmployeeMixin<ParentMixin<HobbyMixin<Person>>>> assmann2;

// Have assmann and assmann2 the same type? HobbyMixin

// Have assmann and assmann2 the same type?
 GenVoca Variations

38 ► When different variants exist for an “abstraction layer”,

parameterizations express configurations of a product line
// Variants
// Variants
Person: Man, Woman
Person: Man, Woman
ParentMixin: FatherMixin, MotherMixin
ParentMixin: FatherMixin, MotherMixin
EmployeeMixin: TimedEmployee, PermanentEmployee
EmployeeMixin: TimedEmployee, PermanentEmployee
Prof. Uwe Aßmann, Design Patterns and Frameworks

HobbyMixin: Gamer, Sportsman, GolfPlayer

HobbyMixin: Gamer, Sportsman, GolfPlayer

// Compositions
// Compositions
GolfPlayer<PermanentEmployee<Father<Man>>>> assmann;
GolfPlayer<PermanentEmployee<Father<Man>>>> assmann;
Gamer<TimedEmployee<Father<Man>>>> miller;
Gamer<TimedEmployee<Father<Man>>>> miller;
GolfPlayer<PermanentEmployee<Mother<Woman>>>> brown;
GolfPlayer<PermanentEmployee<Mother<Woman>>>> brown;
 Variations on Different Abstraction Layers
form Product Variants
39 ► Variants can be formed on every layer

Person Man Woman

<<parameterize>>
Prof. Uwe Aßmann, Design Patterns and Frameworks

ParentMixin Father Mother

<<parameterize>>

Permanent
EmployeeMixin TimedEmployee
Employee

<<parameterize>>

HobbyMixin GolfPlayer PigeonFriend

 Variations on Different Role Layers

40 ► Abstraction layers correspond to role layers of complex objects

► Roles collaborate, but are not implemented by role objects, but
by mixins
Person Man Woman

<<parameterize>>
Prof. Uwe Aßmann, Design Patterns and Frameworks

ParentMixin Father Mother

<<parameterize>>

Permanent
EmployeeMixin TimedEmployee
Employee

<<parameterize>>

HobbyMixin GolfPlayer PigeonFriend

 Discussion

41 ► A mixin layer groups all mixins of a role abstraction layer

► Mixins play in the GenVoca pattern the same role as role
objects in the role object pattern and layered role frameworks
– However, all role objects are embedded into one physical object
– There is a physical identity for the entire logical object
Prof. Uwe Aßmann, Design Patterns and Frameworks

– No object schizophrenia to be avoided

– GenVoca applications are more efficient, since they merge all
roles together into one physical object (see the Aßmann's law on
role merging)
– But: only static extensibility!
► Similarly to layered role object frameworks, layered GenVoca
frameworks can model big product lines
– Every abstraction layer (mixin layer) expresses variability
– New mixin layers model extensibility
 13.5 The Mixin Layer Pattern

42
► While the GenVoca pattern deals with single stacking of parameterizations, the MixinLayer
pattern groups all roles of an abstraction layer together and composes entire layers
► MixinLayer treats all logical objects of an application

Person Work Location

Prof. Uwe Aßmann, Design Patterns and Frameworks

<<parameterize>>

ParentMixin ParentalWork Home

<<parameterize>>

EmployeeMixin WorkRights Workshop

<<parameterize>>

HobbyMixin LeisureWork HobbyLocation

 Mixin Layers as Compositional Unit

43 ► A mixin layer gets a name and can be exchanged consistently

for a variant, changing the behavior of the entire layer
Person Work Location

FullTimeLayer
FullTimePerson FullTimeWork FullTimeLocation
PartTimeLayer PartTimePerson PartTimeWork PartTimeLocation
Prof. Uwe Aßmann, Design Patterns and Frameworks

<<parameterize>>
FatherLayer
Father ChangingDiapers Toilet
MotherLayer Mother BreastFeeding ChildrensRoom

<<parameterize>>
Deliberate NoContract Deliberate Home

ForcedToWork NoContract Forced Home

<<parameterize>>
WorkAsHobby ChildrenAsHobby
WorkNotAs ChildrenNotAs
Hobby Hobby
 Composition of Mixin Layers

44 ► Mixin layers are composed similarly to single GenVoca mixins

– Meaning: All role classes are consistently exchanged with their
layer
CoreLayer: FullTime, PartTime
CoreLayer: FullTime, PartTime
ParentLayer: FatherLayer, MotherLayer
ParentLayer: FatherLayer, MotherLayer
EmployeeLayer: Deliberate, ...
Prof. Uwe Aßmann, Design Patterns and Frameworks

EmployeeLayer: Deliberate, ...

HobbyLayer: WorkAsHobby, Slave....
HobbyLayer: WorkAsHobby, Slave....

// This is now mixin layer composition!

// This is now mixin layer composition!
WorkAsHobby<Deliberate<FatherLayer<FullTime>>>> assmann;
WorkAsHobby<Deliberate<FatherLayer<FullTime>>>> assmann;
 Implementation of Mixin Layers with
GenVoca Pattern and Inner Classes
45 ► The role classes of upper layers form super classes of the layer
class
► The following pattern allows for separate parameterization of all
role mixins, not the layer as a whole
Prof. Uwe Aßmann, Design Patterns and Frameworks

class
class Layer
Layer <class
<class Super,
Super, class
class RoleSuper
RoleSuper1,1, ..,
.., class
class RoleSuper
RoleSupern>n>
extends
extends Super
Super {{
class
class Role
Role1 1 extends
extends RoleSuper
RoleSuper1 1 {{ ..
.. }}
..
..
class
class Role
Rolen extends
extends RoleSuper
RoleSupern {{ .. .. }}
n n

..
.. additional
additional classes..
classes..
}}
 Implementation of Mixin Layers with
Designated Inner Classes
46 ► If the target language permits to have inner classes that can be
designated by an expression, mixin layers can be inherited as a
whole
► The super mixin layer can be selected by one single expression
L<L1>
Prof. Uwe Aßmann, Design Patterns and Frameworks

class
class Layer
Layer <class
<class Super>
Super>
//
// The
The class
class Super
Super has
has nn inner
inner role
role classes
classes RoleSuper
RoleSuper1,, ..,
..,
1
//
// RoleSuper
RoleSupern n
extends
extends Super
Super {{
class
class Role
Role1 1 extends
extends Super.RoleSuper
Super.RoleSuper1 1 {{ ..
.. }}
..
..
class
class Role
Rolen extends
extends Super.RoleSuper
Super.RoleSupern {{ .. .. }}
n n

..
.. additional
additional classes..
classes..
}}
 Example: A Graph Framework [Herrejon
Batory]
47
► Graph applications can be structured into mixin layers
► ConnectedOnDFTUndirected = CRL1<CL1<VN1<TL1<RL1>>>>>
► ConnectedOnBFTRevDirected = CRL1<CL1<VN2<TL2<RL2>>>>>

Graph Node Workspace

Representation
Layer
RL1
GraphUndirected VertexWithAdjac
Prof. Uwe Aßmann, Design Patterns and Frameworks

RL2 GraphDirected VertexWithoutAdj

Traversal
Layer
TL1 DFT VertexDFT
TL2 BFT VertexBFT
Vertex Numbering
Layer
VN1 VertexNumber WorkspaceNumber
VertexReverse
VN2 WorkspaceNumber
Number
CycleLayer

CL1 GraphCycleCheck NodeCycleCheck WorkspaceCycleCheck

ConnectedRegionLayer

CRL1 GraphConnected NodeConnected WorkspaceConnected

 What Have We Learned?

48 ► Extension Objects Pattern

► Extensible Framework Hook Patterns
 Using Role Object Pattern
 Using Genvoca (MixinLayers)
► Role Object Pattern for dynamic extensibility
Prof. Uwe Aßmann, Design Patterns and Frameworks

► Genvoca for static extensibility

Prof. Uwe Aßmann, Design Patterns and Frameworks

49
The End