13. frameworks and patterns - framework extension...
TRANSCRIPT
Design Patterns and Frameworks, © Prof. Uwe Aßmann
1
13. Frameworks and Patterns -Framework Extension Patterns
Prof. Dr. U. AßmannSoftware Engineering Group
Faculty of InformaticsDresden University of Technology
Version 15-1.1, 1/2/16
1)Large Layered Frameworks
2)Role-Object Pattern
1)Flat R.O.P
2)Deep R.O.P
3)Example R.O.P.
3)Treating Object Schizophrenia withR.O.P.
4)Other Variants of R.O.P
5)GenVoca Pattern
6)Mixin Layer Pattern
7)Concerns for Layered Frameworks
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
2
Literature (To Be Read)
► Y. Smaragdakis and D. Batory. Mixin layers: an object-oriented implementationtechnique for refinements and collaboration-based designs. ACM Transactions onSoftware Engineering and Methodology, 11(2):215–255, 2002.
► [flat-ROP] D. Bäumer, D. Riehle, W. Silberski, M. Wulf. Role Object. Conf. On PatternLanguages of Programming (PLOP) 1997 , pp. 15-32 http://citeseer.ist.pst.edu/baumer97role.html
► 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://citeseer.ist.pst.edu/riehle98role.html
► [deep-ROP] 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://citeseer.ist.pst.edu/bumer97framework.html
► [HerejonBatory] Roberto E. Lopez-Herrejon and Don S. Batory. A standard problemfor evaluating product-line methodologies. In Jan Bosch, editor, GCSE, volume 2186of Lecture Notes in Computer Science, pages 10-24. Springer, 2001.
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
3
Further Literature
► D. Bäumer. Softwarearchitekturen für die rahmenwerkbasierte Konstruktion grosserAnwendungssysteme. 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/
► U. Aßmann. Composing Frameworks and Components for Families of Semantic WebApplications. Lecture Notes In Computer Science, vol. 2901, Nov. 2003.
► U. Aßmann, J. Johannes, J. Henriksson, and I. Savga. Composition of rule sets andontologies. 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. Mixin Layers: An object-oriented implementation forrefinements and collaboration-based designs.
► Y. Smaragdakis, D. Batory. Implementing layered designs with mixin layers. InLecture Notes in Computer Science (LNCS) 1998, Springer-Verlag.
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
4
Goal
► Studying extensible framework hook patterns– Understand patterns Extensions Object, Role Object, and
Genvoca– See how layered frameworks can be implemented by Role Object
and Genvoca
► Understand these patterns as extension points of frameworks,i.e., framework hook patterns
► Understand how roles can be implemented in currentmainstream object-oriented languages (e.g., Java, C#)
with delegation in the Role-Object Pattern
► Understand the problem of object-oriented compared to role-oriented programming (Object Schizophrenia)
► Understand the problem of identity and state Delegation versus Forwarding
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
5
Frameworks Must Be Extensible
► 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) – Layered frameworks
● Riehle/Züllighoven's RoleObject pattern (ROP)● Batory's mixin layer pattern (GenVoca pattern)
Design Patterns and Frameworks, © Prof. Uwe Aßmann
6
13.1 Extensibility of Frameworkswith Layers
... with Layered Frameworks based on Roles
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
7
Case Study GEBOS
► GEBOS is a banking application for RWG banking group with450 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 Banks organize themselves in business sections (tellers, loans,
etc.)● Department of specialists that have a certain expertise (loans, teller,
investment) Business domain
Business objects such as bill, order, account Workplace contexts
● Service centers offer customers an all-in-one service● Services of the business sections● Every workplace needs different application systems
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
8
Application Framework Layers
AdviserDesktop
TelephoneBanking
Teller
Application Layers
Teller Loans Investment
Business Section Layers
Account Loan Product
Business Domain Layer
...
...
...
Desktop Layer
Tool
Folders
Values
...
TechnicalKernel Layer
GraphicInterface
Collections
MOP
► Gebos demonstrates that it is advantageous to structure anapplication framework into layers
– Application layers, Business Section layers, Business domain layers– Desktop Layer, Technical kernel layer
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
9
GEBOS Layers
► 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
– 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
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
10
GEBOS Layers
► 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– Subclassing business domain and desktop layers, “inherits” knowledge
from both– Business section concepts: Borrower, investor, garantor, 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
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
11
Goals in Framework Design of GEBOS
► Minimize coupling between frameworks and application systems– Frameworks should never be touched when developing an
application system
► Model different facets of business sections, products, andbusiness domain concepts
– Use role-object design pattern
► Minimize coupling between the layers– Separate concepts from implementation– Move implementation to lower layers
► Achieved with the RoleObject pattern
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
12
The JWAM Framework
► Java WAM (Werkzeug Automat Material) is a layered framework for theTools&Material pattern language www.jwam.de http://sourceforge.net/projects/jwamtoolconstr/
► The JWAM site has a lot of interesting papers, e.g., the PhD thesis ofBäumer
Application Layer
Business Section Layer
Subject Layer (Domain Layer)
...
...
...
Desktop Layer
Tool
Folders
Values
...
TechnicalKernel Layer
Messaging
Collections
MOP
Technical Layer (including JDK)
Language Extension Layer (other frameworks, such as JUnit)
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
13
JWAM has a Kernel
► 100 classes and interfaces► Simple applications can be built with the kernel only► Extensions can be added, extension components:
– Equipment components● Ready to use packages such as desktop, registry, form-service
– Integration components● Database connection...
Design Patterns and Frameworks, © Prof. Uwe Aßmann
14
13.2 The Role-Object Pattern
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
15
Framework Extensibility with Riehles Role-Object Layers
► The Role-Object Pattern (ROP) is both a variability andextensibility 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 coreobjects) with layers of delegatees (role objects)
– A conceptual object (complex object, subject) of theapplication is split over all layers
– Core and role objects conceptually belong together to theconceptual object, but distribute over the layers
– Role objects are views on the conceptual object
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
16
Application Layers
Business Domain Layer
Riehle/Züllighovens Role-Object Pattern (ROP)can be Used in GEBOS-like Architectures
Client
Customer
Guarantor InvestorBorrower
CustomerCore CustomerRole*
potential run-time access
static knowledge
Business Section Layers
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
17
Structure of Flat Role-Object Pattern
Dirk Bäumer, Dirk Riehle, Wolf Siberski, and Martina Wulf: Role Object Pattern. In: Pattern languages of program design (PLoP) 4, pp. 15-32
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
18
Application
Layer 2
Core Layer 1
Riehle/Züllighovens Role-Object PatternVariant 1 (“Flat Roles”)
ClientConceptual
Role2 Role3Role1
Core Role*
<<interfaces>>
<<implementations>>
Layer 3
Role2 Role3Role1
<<implementations>>
► Flat roles: Roles directly know cores
[flat-ROP]
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
19
Run-Time Structure: Flat Roles
<<applicationlayer 2>>
InvestorAppl
<<business domain layer>>CustomerCore
<<business section layer>>Investor
core
role
role
<<application layer 1>>Client
► At runtime, RoleObjects pass service requests (queries) on to the core– RoleObjects are directly linked to the core (flat roles)
– The core redistributes requests to those roles who can deliver the service
Mediator
Colleague
Colleague
core
<<applicationlayer 2>>StockAppl
role
core
Colleague
Design Patterns and Frameworks, © Prof. Uwe Aßmann
20
13.2.2 Variant 2: The Deep Role-Object Pattern
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
21
Application Layers
Business Domain Layer
Deep Role-Object Pattern (ROP)[Riehle/Züllighoven]
Client
Customer
Guarantor InvestorBorrower
CustomerCore CustomerRole*
potential run-time access
static knowledge
Business Section Layers
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
22
Application Layer
Business Section Layers
Business Domain Layer
Deep Role-Object Pattern
Client
Customer
Guarantor InvestorBorrower
CustomerCore CustomerRole*
<<interfaces>>
<<implementations>>
<<template classes>>
<<static>>
<<dynamic>>
[deep-ROP]
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
23
Run-Time Structure: Deep Roles
<<applicationlayer 2>>
InvestorAppl
<<business domain layer>>CustomerCore
<<business section layer>>Investor
next
role
role
<<application layer 1>>Client
► At runtime, RoleObjects pass service requests (queries) on to the core– RoleObjects can be stacked in a Decorator chain (deep roles)
► The core knows all RoleObjects, and distributes requests (Mediator)– The core manages the RoleObjects in a map that can be dynamically extended
Mediator
Colleague
Colleague
next<<application
layer 2>>StockAppl
role
Colleague
Decorator
Decorator
Decorator
Decorator
Decoratee
next
next
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
24
Variant “Flat Roles”: Run-Time Structure
<<applicationlayer 2>>
InvestorAppl
<<business domain layer>>CustomerCore
<<business section layer>>Investor
next
role
role
<<application layer 1>>Client
► At runtime, RoleObjects pass service requests (queries) on to the core– RoleObjects can be stacked in a Decorator chain
► The core knows all RoleObjects, and distributes requests (Mediator)– The core manages the RoleObjects in a map that can be dynamically extended
Mediator
Colleague
Colleague
next
<<applicationlayer 2>>StockAppl
role
Colleague
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
25 Application
Layer 2
Core Layer 1
Role-Object Pattern with More Layers(“Deep Roles”)
ClientConceptual
Role2 Role3Role1
Core Role*
<<interfaces>>
<<implementations>>
Layer 3
Role2 Role3Role1
<<implementations>>[deep-ROP]
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
26
Application
Core Layer
Structure of Core Layer Client
Conceptual
Core Role*
service1()service2()service3()
addRole()removeRole()
hasRole()giveRole()
service1()service2()service3()
addRole()removeRole()
hasRole()giveRole()
addRole()removeRole()
hasRole()giveRole()
service1()service2()service3()
<<delegate>>
new
► Management functions control theallocation of roles
► Services are■ directly available (black): role object
is registered, service in role object■ available (red): then role object is
registered; service is not in role, butcan be delegated via core
■ loadable (green): interface exists in“Conceptual”, but role must becreated and registered to bedelegatable; role map must be boundwith role object
■ loadable and hidden (blue): thenservice is defined in a role subclass,NOT existing in “Conceptual”; but canbe loaded and accessed from the roledirectly; role map must be extended
Role Map
SubRole
service4()
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
27
Run-time Behavior of ROP
► Change of role:– Different Role Objects may belong to the same role type (same
ability)– Over time, the role object for a role type may change, due to
polymorphic behavior of the role– This expresses states of the role type in the application– E.g., Borrower --> UnsafeBorrower --> TrustedBorrower
► Roles are created on-demand– In the beginning, the Subject is slim, i.e., carries few roles.– At service requests, the core creates roles and enters them in
the role map
► Roles are invisible: – The protocol of the role-object Pattern mediates all service
requests to the right role via the core
Design Patterns and Frameworks, © Prof. Uwe Aßmann
28
13.2.3 Role-Object PatternEmail Example
A Dialog asking a User for itsEMail-Address
[Courtesty to Dr. Sebastian Götz]
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
29
A Dialog Requesting an Email-Address
Provide EMail-Address
Please provide your Email-Address:
OKCancel
► User shall provide his Email-Address► Application want's to ensure that the provided address is valid
(Pattern: [email protected])
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
30
A Dialog Requesting an Email-Address
Provide EMail-Address
Please provide your Email-Address:
OKCancel
► User shall provide his Email-Address► Application want's to ensure that the provided address is valid
(Pattern: [email protected]) ► Application want's to visualize invalid Email-Addresses
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
31
Purpose of Role-Object Pattern
► Transparently adapting objects to client context► Management of role playership, where roles are represented
as individual objects
addressField: TextFieldChild
root : Dialog
Parent
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
32
Purpose of Role-Object Pattern
► Transparently adapting objects to client context► Management of role playership, where roles are represented
as individual objects
addressField: TextFieldChild DataSource
root : Dialog
Parent
formProcessor : Validator DataSink
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
33
Purpose of Role-Object Pattern
► Transparently adapting objects to client context► Management of role playership, where roles are represented
as individual objects
addressField: TextFieldChild DataSource
root : Dialog
Parent
formProcessor : Validator DataSink
2nd Client = 2nd Context =Validation
1st Client = 1st Context = Drawing
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
34
Running Example: Email Checking
TextFieldCore
Child DataSource
TextFieldRole
TextField
Parent DataSink
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
35
Roles Can be “Allocated”
description: TextFieldCore
descriptionChild: Child
addRole(descriptionChild);
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
36
..and Exchanged...
description: TextFieldCore
descriptionChild: Child
addRole(descriptionDS);
descriptionDS: DataSource
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
37
Here: Both Roles are Alternatives
description: TextAreaCore
removeRole(descriptionChild);
descriptionDS: DataSource
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
38
Running Example: Email Checking
description: TextAreaCore
descriptionChild: Child
descriptionDS: DataSource
drawer : Parent
validator : DataSink
Design Patterns and Frameworks, © Prof. Uwe Aßmann
39
11.3 Treating ObjectSchizophrenia with ROP
How the Problem of SplitObjects is Treated by the ROP
Protocol
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
40
The Problem of Split Objects
► Object schizophrenia covers the problems, which arise fromsplitting a conceptual object into multiple parts.
TextField
DataSourceChild
TextField
DataSourceChild
TextField
text : Stringparent : Parent
TextField
text : String
Child
parent : Parent
DataSource
text : String
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
41
The Problem of Split Objects
► Object schizophrenia arises from splitting a conceptual objectinto multiple parts:
► Question for identity depends on which object is asked.“Who are you?”
User: “I'm a TextField.” Drawer: “I'm the child of this parent.” Validator: “I'm a data source for you.”
TextField
DataSourceChildUser
Drawer Validator
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
42
The Problem of Split Objects
► Who manages the state of the compound object? The text of the field is required for both roles The size of the field is specific to the drawing task The color of the text crosscuts both roles (drawing + validation)
► When should a role delegate to the player and when should a playerdelegate to its roles?
TextField
DataSourceChildUser
Drawer Validator
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
43
The ROP Protocol Treats ObjectSchizophrenia
► Clients may have access to a role or the core► If the role does not directly provide the service, it will pass it on to the
core object The clients implicitly “ask” the core object (the mediator)
► The core object delegates the call to the respective role► The core object represents the identity, asking questions for
THIS/SELF► The core manages its roles and creates them on-demand
Role management code AddRole, RemoveRole, Operation
Code for reflection HasRole, GetRole
► Roles need to be implemented aware of their core Delegation to core object for every method call, as it could be
overridden by another role object, which is currently being played.
Design Patterns and Frameworks, © Prof. Uwe Aßmann
44
11.3.2 Delegation vs.Forwarding
The meaning of this
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
45
Delegation vs. Forwarding
► What does this or self actually mean?
ClassA ClassB
m1()m2()
m1()m2()
class B { A a; m1() { a.m1(); } m2() { print(“B”); }}
a
class A { m1() { this.m2(); } m2() { print(“A”); }}
a = new A();b = new B(a);
b.m1();
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
46
Delegation Changes this While RunningThrough References
► this or self is changed during traversal of references
► Delegation Semantics:this bound to delegatee(i.e., this = a)
ClassA ClassB
m1()m2()
m1()m2()
class B { A a; m1() { a.m1(); } m2() { print(“B”); }}
a
class A { m1() { this.m2(); } m2() { print(“A”); }}
// client codea = new A();b = new B(a);
b.m1();
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
47
// client codea = new A();b = new B(a);
b.m1();
Forwarding Retains this While RunningThrough References
► Forwarding “stays” within one object
► Forwarding Semantics:no delegation of this(i.e., this = b)
ClassA ClassB
m1()m2()
m1()m2()
class B { A a; m1() { a.m1(); } m2() { print(“B”); }}
a
class A { m1() { this.m2(); } m2() { print(“A”); }}
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
48
Forwarding in Java
► Java does not directly support forwarding Workaround required: Passing this to the receiver
► Keep this in mind when implementing operations in the Role-Object Pattern!
ClassA ClassB
m1(me : Object)m2()
m1()m2()
class B { A a; m1() { a.m1(this); } m2() { print(“B”); }}
a
class A { m1(Object me) { me.m2(); } m2() { print(“A”); }}
Design Patterns and Frameworks, © Prof. Uwe Aßmann
49
13.4 Variants of the Role-Object Pattern
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
50
Application
Layer 2
Core Layer 1
Rpt.: Role-Object Pattern Variant 1 (“FlatRoles”)
ClientConceptual
Role2 Role3Role1
Core Role*
<<interfaces>>
<<implementations>>
Layer 3
Role2 Role3Role1
<<implementations>>
► Flat roles: Roles directly know cores
[flat-ROP]
<<dynamic>>
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
51Application Layer
Business Section Layers
Business Domain Layer
Variant 2: Deep Role-Object Pattern
Client Customer
Guarantor InvestorBorrower
CustomerCore CustomerRole*
<<interfaces>>
<<implementations>>
<<template classes>>
<<static>>
<<dynamic>>
[deep-ROP]
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
52
Core Layer 1
Variant 3: Core Layer with Traded Call
Conceptual
Core *
<<interfaces>>
accept(ServiceDescription)service1()
addRole()removeRole()
hasRole()giveRole()
accept(ServiceDescription)service1()
addRole()addRole(ServiceDescription)
removeRole()hasRole()giveRole()
Role
addRole()removeRole()
hasRole()giveRole()
accept(ServiceDescription)service1()
Role Map
// Traded call //Interpret serviceDescription;Lookup concrete service in role map;Call;
► To add services dynamically (beyond the service interfaces in theconceptual object), add a trader to the core
● A trader is a method that interprets a service request based on a servicedescription
// enter traded role //Interpret serviceDescription;add concrete role and service under service description in role map;
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
53
RoleObjectPattern and Other Patterns
► Deep-ROP is not only a Decorator with Mediator– It is based on 1-H<=T, i.e., 1-ObjectRecursion
● All role objects inherit from the abstractum● 1-ObjectRecursion based patterns lend themselves to extension
– And 1-H<=T framework hook patterns provide extensibleframeworks
– 1:n relationship between core and role objects– Role objects decorate the core object, and pass requests on to
it
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
54
Business Section Loan Layer
Business Section Investment Layer
Business Domain Layer
Role-Object Pattern Vs Inheritance (White-Box Framework Layers)
Customer
Investor
Borrower
CustomerCore CustomerRole*
Account
SavingsAccount
LoanAccount
<<whitebox framework (H<T)>><<ROP framework>>(n-TrH)
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
55
Business Section Loan Layer
Business Section Investment Layer
Business Domain Layer
Role-Object Pattern Vs Inheritance (White-Box Framework Layers)
Customer
Investor
Borrower
CustomerCore CustomerRole*
Account
SavingsAccount
LoanAccount
AccountCore AccountRole*
<<ROP framework>>(n-TrH)
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
56
Comparison of Role Objects withInheritance
► White-Box frameworks rely on inheritance as mini-connector(H<T)
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,business) affect other layers
– Changes in the business section layers do not affect the businessdomain layers
► The relation of core and role objects is a special form of part-of(combined with inheritance)
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
57
Business Section Loan Layer
Business Section Investment Layer
Business Domain Layer
Role-Object Pattern with Template andHook Stereotypes
Customer
Investor
Borrower
CustomerCore CustomerRole*
Account
SavingsAccount
LoanAccount
AccountCore AccountRole
<<template class>>
<<template class>>
<<template class>>
<<template class>> <<hook class>><<hook class>>*
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
58
Business Section Loan Layer
Business Section Investment Layer
Business Domain Layer
Role-Object Pattern and Role Models onRole Layers
Customer
Investor
Borrower
CustomerCore CustomerRole*
Account
SavingsAccount
LoanAccount
AccountCore AccountRole*
► Usually, roles of one subject talk to other roles of another subject on thesame layer (within a role model)
► Cores never talk to each other directly
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
59
Switching Variable Role Layers
► At run time, entire role models on role layers can be exchanged(variable role layers)
Business Section Loan Layer
Business Section Investment Layer
Business Domain Layer
Customer
Garantor
Borrower
CustomerCore CustomerRole*
Account
GaranteeContract
LoanAccount
AccountCore AccountRole*
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
60
Riehle/Züllighovens Layer Pattern AsFramework Hook Pattern
C
R
Core-Role-Pattern
R
R
C
n-TrH mini-connector
R
Conceptual
Role n-TrHT2 has H parts
H and T2 inheritfrom T1
Core
Special partOf
Con
T1
H
T2
n n
n
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
61
ROP Ensures Extensibility
► The ROP lends itself not only to variability, but also to staticand dynamic extensibility
– If a framework hook is a Role-Object Pattern, the hook can beextended in unforeseen ways without changing the framework!
– New layers of the application or the framework can be added atdesign time or runtime
► Powerful extension concept with ROP-Trader– Whenever you have to design something complex which should
be extensible in unforeseen ways, consider Role Object
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
62
Riehle/Züllighovens Layered Role ObjectFramework
C
RCore Layer
R
R
Role Layer 1 Role Layer 2 Role Layer 3
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
63
Extension in Layered Role Object Frameworks
C
RCore Layer
R
R
Role Layer 1 Role Layer 2 Role Layer 3
R
Role Layer 4
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
64
ROP Can Implement Dimensions That AreNot Independent
► The role objects implement dimensions– Core object implements primary dimension– Role object secondary dimension
► Role objects realize one conceptual object, instead of a rolemodel crosscutting several conceptual objects
– Facets are independent dimensions of a conceptual objects– Every dimension can be varied independently
► ROP generalizes the implementation of facets by Multi-Bridge(see Chapter “Simple Extensibility”)
– Multi-Bridge has no inheritance between ConceptualObject, Coreand Role
– Multi-Bridge suffers from object schizophrenia, ROP canimplement “this()” on itself without object schizophrenia
– Calls to the role are not dispatched to the LogicalObject– Bridges must not inherit from each other, RoleObjects can
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
65
Beneft ofLayered Role-Object Frameworks
► Implements conceptual objects with layered dependentdimensions
– Not only independent dimensions
► Together with layering, – Easily extensible– Enormous variability– Simple structure for extensible product line architecture results
► For instance: Layered Frameworks for Business Software– Dispatch on all layers is necessary
● Implementation without multimethods (in standard languages)very hard. Only CLOS, Cecil, and MultiJava are good here
– That is one reason why business frameworks are so hard● SanFrancisco business framework of IBM didn't make it though
a dynamic extensibility pattern● That's also why these applications are so expensive
Design Patterns and Frameworks, © Prof. Uwe Aßmann
66
13.5 The GenVoca Pattern, MixinLayers, and Layered MixinFrameworks
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
67
The Mixin Concept
► A mixin is a partial class, for an extension of another class
► A mixin-base is a class with a generic super, a mixin parameterizes this generic super
► Some languages have mixins (Scala, C#, Eiffel); otherwise, mixins can be expressed as classfragments that can be parameterized with a superclass (C++)
► Mixins can implement (static) roles and facets
template <class Super> class EmployeeMixin extends Super {
// class extension..Salary salary;Employer emp;
}
template <class Super> class EmployeeMixin extends Super {
// class extension..Salary salary;Employer emp;
}
EmployeeMixin<Person> employeeOfPerson;EmployeeMixin<German> employeeOfGerman;EmployeeMixin<Club> employeeOfClub;
EmployeeMixin<Person> employeeOfPerson;EmployeeMixin<German> employeeOfGerman;EmployeeMixin<Club> employeeOfClub;
Person
EmployeeMixin
<<parameterize>>
EmployedPerson
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
68
The GenVoca Pattern
► If several mixin parameterizations are nested, the GenVocapattern results [Batory]
// C++-like syntaxtemplate <class S> class EmployeeMixin extends S {
Salary salary;Employer emp;
}template <class S> class ParentMixin extends S {
Child child;Money kindergeld;
}template <class S> class HobbyMixin extends S {
Hobby hobby;}// Persons composed with GenVoca patternHobbyMixin<ParentMixin<EmployeeMixin<Person>>>> assmann;EmployeeMixin<ParentMixin<HobbyMixin<Person>>>> assmann2;// Have assmann and assmann2 the same type?
// C++-like syntaxtemplate <class S> class EmployeeMixin extends S {
Salary salary;Employer emp;
}template <class S> class ParentMixin extends S {
Child child;Money kindergeld;
}template <class S> class HobbyMixin extends S {
Hobby hobby;}// Persons composed with GenVoca patternHobbyMixin<ParentMixin<EmployeeMixin<Person>>>> assmann;EmployeeMixin<ParentMixin<HobbyMixin<Person>>>> assmann2;// Have assmann and assmann2 the same type?
Person
EmployeeMixin
ParentMixin
HobbyMixin
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
69
GenVoca Variations
► When different variants exist for a “abstraction layer”,parameterizations express configurations of a product line
// VariantsPerson: Man, WomanParentMixin: FatherMixin, MotherMixinEmployeeMixin: TimedEmployee, PermanentEmployeeHobbyMixin: PigeonFriend, Sportsman, GolfPlayer
// CompositionsGolfPlayer<TimedEmployee<Father<Man>>>> assmann;PigeonFriend<PermanentEmployee<Father<Man>>>> miller;GolfPlayer<PermanentEmployee<Mother<Woman>>>> brown;
// VariantsPerson: Man, WomanParentMixin: FatherMixin, MotherMixinEmployeeMixin: TimedEmployee, PermanentEmployeeHobbyMixin: PigeonFriend, Sportsman, GolfPlayer
// CompositionsGolfPlayer<TimedEmployee<Father<Man>>>> assmann;PigeonFriend<PermanentEmployee<Father<Man>>>> miller;GolfPlayer<PermanentEmployee<Mother<Woman>>>> brown;
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
70
Variations on Diferent Abstraction Layersform Product Variants
► Variants can be formed on every layer
Person
ParentMixin
<<parameterize>>
EmployeeMixin
<<parameterize>>
HobbyMixin
<<parameterize>>
Man
Father
TimedEmployee
GolfPlayer
PermanentEmployee
PigeonFriend
Woman
Mother
PermanentEmployee
GolfPlayer
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
71
Variations on Diferent Role Layers
► Abstraction layers correspond to role layers of complex objects► Roles collaborate, but are not implemented by role objects, but
by mixins
Person
ParentMixin
<<parameterize>>
EmployeeMixin
<<parameterize>>
HobbyMixin
<<parameterize>>
Man
Father
TimedEmployee
GolfPlayer
PermanentEmployee
PigeonFriend
Woman
Mother
PermanentEmployee
GolfPlayer
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
72
Discussion
► 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– 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 onrole merging)
► Similarly to layered role object frameworks, layered GenVocaframeworks can model big product lines
– Every abstraction layer (mixin layer) expresses variability– New mixin layers model extensibility
Design Patterns and Frameworks, © Prof. Uwe Aßmann
73
13.6 The Mixin Layer Pattern
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
74
The Mixin Layer Pattern Combines SeveralGenVoca Patterns► 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
ParentMixin
<<parameterize>>
EmployeeMixin
<<parameterize>>
HobbyMixin
<<parameterize>>
Work
ParentalWork
WorkRights
LeisureWork
Location
Home
Workshop
HobbyLocation
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
75
FullTimePerson FullTimeWork FullTimeLocation
PartTimePerson PartTimeWork PartTimeLocation
FullTimeLayer
PartTimeLayer
Mixin Layers as Compositional Unit
► A mixin layer gets a name and can be exchanged consistentlyfor a variant, changing the behavior of the entire layer
Person
Father
<<parameterize>>
<<parameterize>>
Work
ChangingDiapers
Location
Toilet
Mother BreastFeeding ChildrensRoom
NoContract Deliberate Home
NoContract Forced Home
<<parameterize>>
ChildrenAsHobby
FatherLayer
MotherLayer
ForcedToWork
Deliberate
WorkAsHobby
WorkNotAsHobby
ChildrenNotAsHobby
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
76
Composition of Mixin Layers
► Mixin layers are composed similarly to single GenVoca mixins– Meaning: All role classes are consistently exchanged with their
layerCoreLayer: FullTime, PartTimeParentLayer: FatherLayer, MotherLayerEmployeeLayer: Deliberate, ...HobbyLayer: WorkAsHobby, Slave....
// This is now mixin layer composition!WorkAsHobby<Deliberate<FatherLayer<FullTime>>>> assmann;
CoreLayer: FullTime, PartTimeParentLayer: FatherLayer, MotherLayerEmployeeLayer: Deliberate, ...HobbyLayer: WorkAsHobby, Slave....
// This is now mixin layer composition!WorkAsHobby<Deliberate<FatherLayer<FullTime>>>> assmann;
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
77
Implementation of Mixin Layers withGenVoca Pattern and Inner Classes
► The role classes of upper layers form super classes of the layerclass
► The following pattern allows for separate parameterization of allrole mixins, not the layer as a whole
► The role classes of upper layers form super classes of the layerclass
► The following pattern allows for separate parameterization of allrole mixins, not the layer as a whole
// Java-like syntaxclass Layer <class Super, class RoleSuper
1, .., class RoleSuper
n>
extends Super {class Role
1 extends RoleSuper
1 { .. }
..class Role
n extends RoleSuper
n { .. }
.. additional classes..}
// Java-like syntaxclass Layer <class Super, class RoleSuper
1, .., class RoleSuper
n>
extends Super {class Role
1 extends RoleSuper
1 { .. }
..class Role
n extends RoleSuper
n { .. }
.. additional classes..}
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
78
Implementation of Mixin Layers withDesignated Inner Classes
► If the target language permits to have inner classes that can bedesignated by an expression, mixin layers can be inherited as awhole
► The super mixin layer can be selected by one single expressionL<L1>
class Layer <class Super> // The class Super has n inner role classes RoleSuper
1, ..,
// RoleSupern
extends Super {class Role
1 extends Super.RoleSuper
1 { .. }
..class Role
n extends Super.RoleSuper
n { .. }
.. additional classes..}
class Layer <class Super> // The class Super has n inner role classes RoleSuper
1, ..,
// RoleSupern
extends Super {class Role
1 extends Super.RoleSuper
1 { .. }
..class Role
n extends Super.RoleSuper
n { .. }
.. additional classes..}
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
79
GraphUndirected VertexWithAdjac
GraphDirected VertexWithoutAdj
RepresentationLayer
Example: A Graph Framework [HerrejonBatory]► Graph applications can be structured into mixin layers
► ConnectedOnDFTUndirected = CRL1<CL1<VN1<TL1<RL1>>>>>
► ConnectedOnBFTRevDirected = CRL1<CL1<VN2<TL2<RL2>>>>>
Graph
DFT
Node
VertexDFT
Workspace
BFT VertexBFT
VertexNumber WorkspaceNumber
VertexReverseNumber
WorkspaceNumber
GraphCycleCheck
TraversalLayer
Vertex NumberingLayer
CycleLayer
ConnectedRegionLayer
GraphConnected
NodeCycleCheck WorkspaceCycleCheck
NodeConnected WorkspaceConnected
CL1
CRL1
VN2
VN1
TL2
TL1
RL2
RL1
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
80
Layered Mixin Frameworks vsLayered Role Object Frameworks
► Every mixin layer corresponds to a role layer► Mixin layers form frameworks that can be extended by mixin
layer composition towards applications► Same variability effects for big product lines
Person
ParentMixin
EmployeeMixin
HobbyMixin
Work
ParentalWork
WorkRights
LeisureWork
AdviserDesktop
TelephoneBanking
Teller
Application Layers
Teller Loans Investment
Business Section Layers
Account Loan Product
Business Domain Layer
...
...
...
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
81
Layered Mixin Frameworks vsLayered Role Object Frameworks
► Unfortunately, the direction of generality is usually drawn in theopposite way in mixin layer frameworks and role objectframeworks
► If we agree to put the “most general abstraction layer”downmost, the dependencies go into the same direction
► Features on the upper layers depend on the lower layers
Person
ParentMixin
EmployeeMixin
HobbyMixin
Work
ParentalWork
WorkRights
LeisureWork
AdviserDesktop
TelephoneBanking
Teller
Application Layers
Teller Loans Investment
Business Section Layers
Account Loan Product
Business Domain Layer
...
...
...
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
82
Layered Mixin Frameworks vsLayered Role Object Frameworks
► Essentially, layered role object frameworks and layered mixinframeworks provide the same concept for variability andextensibility
► Difference: mini-connector– Layered role object frameworks use as mini-connector the Role-
Object Pattern– Layered mxin frameworks use as mini-connector the GenVoca
pattern
Design Patterns and Frameworks, © Prof. Uwe Aßmann
83
13.7 How To Find Concerns for aLayered Framework
Example: Layered Frameworks for the Semantic Web
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
84
Example: A New Application Area: Semantic Web Applications
► Semantic web:– Standardization technology for the Web and many application
domains– Definition of ontologies, standard dictionaries– Based on inheritance and constraints
► Every application domain will have its “Semantic Web ontology”► How to build product families for those domains?
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
85
Component Language Semantics
Component Model
Architectural Style Constraints
Application Family Constraints
Application Constraints
User Constraints (Personalization)
Architectural Concerns
Core Conceptual Concerns
Application Concerns
The Concerns of an Application in theSemantic Web
► Which concerns exist?► After a little thought: three groups of concerns. (This is not
complete, there might be more)
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
86
Layered Frameworks for Product Lines onthe Semantic Web
► We can sort the acyclically dependent concerns into a layeredarchitecture, in which several ComplexObjects crosscut all layers
– On every level, there are constraints to check the layer for consistency– All role objects on the layer are checked by the constraints
Generic Component Layer
Composition Time Layer
Component Language Layer
Concrete Component Model Layer
Architectural Style Layer
Application Family Layer
Application Layer
User Layer (Personalization)
Architectural Layers
Core Conceptual Layers
Application LayersConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
87
Layered Frameworks for CompositionSystems
► Even a composition system for web applications can bearranged in role layers
Generic Component Layer
Composition Time Layer
Component Language Layer
Concrete Component Model Layer
Architectural Style Layer
Application Family Layer
Application Layer
User Layer (Personalization)
Architectural Layers
Core Conceptual Layers
Application LayersConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
ConcernConstraints
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
88
Layers can be Instantiated Diferently
► On every layer of the layered framework, there is variation andextensibility
► New user constraints► New application constraints► New application family constraints► New architectural constraints► New component models► New component languages
► Different Languages in One Framework– Since the language is a layer, it can be exchanged– Several ontology languages can be used for components in
Semantic Web applications● BPEL, Datalog, Prolog, OWL
Generic Component Layer
Composition Time Layer
Component Language Layer
Concrete ComponentModel Layer
Architectural Style Layer
Application Family Layer
Application Layer
User Layer (Personalization)
Component
Architectural Layers
Core Conceptual Layers
Application Layers
FragmentComponent
Datalog
Prolog
BinaryDatalog
OWL
WebServices Model
Transaction-basedWeb Services Model
Banking Transaction-basedWeb Services
MoneyDeposit Inc.Web Services
Uwe AssmannBanking Portfolio
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
90
Diferent Architectures are Possible forOne Component Model
► Since the architectural styles can be exchanged for the samecomponent model
Generic Component Layer
Composition Time Layer
Component Language Layer
Concrete ComponentModel Layer
Architectural Style Layer
Application Family Layer
Application Layer
User Layer (Personalization)
Component
Architectural Layers
Core Conceptual Layers
Application Layers
FragmentComponent
Datalog
EJB
BinaryDatalog
JSP
RuntimeComponent
Tax Event-basedWeb Services
Tax AuthoritiesWeb Services
Uwe AssmannTex Portfolio
Event-basedWeb Services Model
Transaction-basedWeb Services Model
Banking Transaction-basedWeb Services
MoneyDeposit Inc.Web Services
Uwe AssmannBanking Portfolio
WebServices Model
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
92
Diferent Component Models Can Coexist
► Interoperability of Semantic Web application is simplified
Generic Component Layer
Composition Time Layer
Component Language Layer
Concrete ComponentModel Layer
Architectural Style Layer
Application Family Layer
Application Layer
User Layer (Personalization)
Component
Architectural Layers
Core Conceptual Layers
Application Layers
FragmentComponent
Datalog
EJB
BinaryDatalog
JSP
Web Services Model I
RuntimeComponent
Tax Event-basedWeb Services
Tax AuthoritiesWeb Services
Uwe AssmannTex Portfolio
Event-basedWeb Services Model
Transaction-basedWeb Services Model
Banking Transaction-basedWeb Services
MoneyDeposit Inc.Web Services
Uwe AssmannBanking Portfolio
Web Services Model II
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
94
Layered Frameworks and ComponentModels
► Once, if languages and component models are layers, layeredframeworks can be generalized considerably.
– Implementation with Layered ROP frameworks or Layered mixinframeworks
► It becomes possible to build totally heterogeneous applications:– Different framework and component languages– Different architectures and architectural styles– Different product lines (application families)
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
95
What Have We Learned?
► How can we structure a Product Line as Layered Framework?– ExtensionObjects is a simple extension mechanism for frameworks– Layered frameworks provide variability and extensibility for thousands of
different products in a product line
► Process for layered frameworks:– Identify concerns (abstraction layers), which crosscut all or many
objects. These concerns are similar to facets, but not independent– Sort them according to their (acyclic) dependencies– Use ROP or Genvoca pattern for implementation– Use framework role layers or mixin layers for a layered application
► The Role-object Pattern Realization of roles in object-oriented languages Using delegation and forwarding
► Object Schizophrenia Problem of identity Problem of state management
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
96
The End
Design Patterns and Frameworks, © Prof. Uwe Aßmann
97
13.A.1 The ExtensionObjectsPattern (EOP)
Extensions of Objects, visibile for the Client
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
98
Structure of ExtensionObjects
► 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
Subject
ConcreteExtension2
ConcreteExtension3
ConcreteExtension1
Extension
1 or n
AbstractExtension
getExtension(name)addExtension(name, Extension)removeExtension(name)
ConcreteSubject
getExtension(name)addExtension(name, Extension)removeExtension(name)
extension
owner
Client
AbstractExtension
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
99
Example: Spellcheckers in DocumentModels
► E.g., OpenDoc or OLE documents
Document
EnglishSpellchecker
GermanSpellchecker
FrenchSpellchecker
Extension
1 or n
<<template>>
Spellchecker
getExtension(name)addExtension(name, Extension)removeExtension(name)
ConcreteDocument
getExtension(name)addExtension(name, Extension)removeExtension(name)
extension
owner
Client
WordCounter
<<hook>>
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
100
Discussion of EOP
► 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– 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 isthe 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
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
101
Framework
ExtensionObjects at Framework Borders
► Since with EOP, clients have to manage extensions themselves,the use of the template object in the framework does not help touse the hook objects
Subject
ConcreteExtension2
ConcreteExtension3
ConcreteExtension1
Extension
1 or n
<<template>>
AbstractExtension
getExtension(name)addExtension(name, Extension)removeExtension(name)
ConcreteSubject
getExtension(name)addExtension(name, Extension)removeExtension(name)
extension
owner
Client
AbstractExtension
<<hook>>
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
102
EOP as Framework Hook Pattern
► Since the hook object is not mandatory, also 1-H=T is a realextensibility pattern for frameworks
T H
n-H=TT has n H partsT owns H parts
nT H
1-H=TT has 1 H partT owns H
1
T H= T H=*
Pro
f. U
we
Aß
ma
nn, D
esig
n P
att
e rns
an d
Fra
me
wo
rks
103
Optional Tools for Documents in an OfceFramework
Office Framework
SpellChecker
Document
WordCount
=*
a.s.o