1 collaboration-based role-oriented programming kasper b. graversen
Post on 20-Dec-2015
215 views
TRANSCRIPT
1
Collaboration-Based Role-Oriented Programming
Kasper B. Graversen
2
Today’s menu…
Roles dynamic specialization of object
Collaborations focus on processes
3
The OOP advocacy
“The terminology of the problem domain/real world is found as entities in the solution domain.” But this is a simplistic view, since what an
“account” is to a bank customer is entirely different from what the same “account” is to the bank system. User: balance, withdraw, deposit Bank system: logging, interest calculations, transactions How should class Account then look like?
4
Context and objects
Phenomena are typically represented as objects. But what possibilities does OOP offer?
Aggregation - Not of the same type - No late binding of self - Methods are not inherited - No Id + Dynamic + Multiplicity
Account
Role A Role B
5
Context and objects
Phenomena are typically represented as objects. But what possibilities does OOP offer?
Aggregation - Not of the same type - No late binding of self - Methods are not inherited - No Id + Dynamic + Multiplicity
Account
Role A Role B
6
Context and objects
Inheritance + Of the same type + Late binding of self + Methods are inherited + Same id - Dynamic - (Multiplicity)
Account
Role A Role B
7
Several roles instances can be attached to the same intrinsic object. Each role represents the object in a given context.
Role extensions are only visible to those who references the intrinsic object through the role instance.
If a role instance changes the state of an intrinsic object, then the value is changed for all attached roles.
Roles and visibility
RA
StudentCourses[];
Teacherweekhours;
PersonCalendar;
name;address;
a
b
c
8
Roles and programming
The notion of classes focuses on the capabilities of objects.
The notion of roles focuses on the position and responsibility of an object within the overall structure of objects.
We get clear separation of concerns.
9
Roles for roles – a context in a context A role being a role for a role.
Enables extensions of an already extended object. Role semantics
activation/deactivation, moving, removing, constraining two concurrent roles
Original system1st extension
Teacherweekhours;
PersonCalendar;
name;address;
WageEarnersalary;
getSalary()
BonusWagegetSalary()
2nd extension
10
The difference between class and role inheritance
Roles are dynamic and non-exclusive
A
B C
Compile-time: A or B or CDistinct entities of a family A
Run-time: A or AB or AC or ABC or ABBBContext for entity A
A
B C
11
The difference between class and role inheritance
Roles are dynamic and non-exclusive
A
B C
Compile-time: A or B or CDistinct role entities of a family A
Run-time: A or AB or AC or ABCDefines contexts B, C for context A
A
B C
rolesubclass
rolefor role
12
Roles adaptive behavior
• “Roles for roles” are applied where further specialization is needed.
Course Administration System
StudentCourses[]
Active selectCourse()
Inactive
Student-AsIncome amount
University Economy System
PersonCalendar
NameAddress
WageEarnersalary
getSalary()
Room
Calendar
Courseint points
• Roles are only used where dynamics occurs
• A new system easily adapts on top of the existing.
• Role constraint support
Teacherweekhours
13
Constituent methods Are invoked regardless of reference (either
through role or intrinsic). Invoked around the original method (it can
completely take over the method call if needed).
Can be used as e.g. input/output filters. Observer ...
salary += calcBonus();return salary;
wage = earner.getSalary();
BonusWage WageEarner
double salary;
double getSalary(){ return salary;}
12
3
14
Constituents Needed in order to express flexible extensions
on the same entry point or to overcome “reference hell”
foom()
15
Constituents Needed in order to express flexible extensions
on the same entry point or to overcome “reference hell”
foom()
logging
16
Constituents Needed in order to express flexible extensions
on the same entry point or to overcome “reference hell”
foom()
logging caching
17
Constituents Needed in order to express flexible extensions
on the same entry point or to overcome “reference hell”
foom()
logging caching
?
18
Constituents Needed in order to express flexible extensions
on the same entry point or to overcome “pointer hell”
foom()
loggingcaching
constituent method binding
m()m()
19
Class roles
Are written for the class Every instance of that class will have such a
role automatically attached Limitations the constructor in that it cannot take
arguments Only really useful if the role contains constituent
methods due to the ‘multiple view’ property
20
Collaborations
21
What’s wrong with this picture? Roles are sort of dangling. Roles are divided in two groups, but this is
difficult to see and is not reflectedin the object-structure.
StudentCourses[]
Active selectCourse()
Inactive
Student-AsIncome amount
PersonCalendar
NameAddress
Teacherweekhours
WageEarnersalary
getSalary()
22
What’s wrong with this picture? Roles are sort of dangling. Roles are divided in two groups, but this is
difficult to see and is not reflectedin the object-structure.
StudentCourses[]
Active selectCourse()
Inactive
Student-AsIncome amount
PersonCalendar
NameAddress
Teacherweekhours
WageEarnersalary
getSalary()
23
Collaborations
Collaborations represents processes
++
collaboration hospitalization { state Patient {} Nurse {} Doctor {} public functionality(){} private functionality(){}}
Functionality regarding the process is encapsulated
…and placed in well-defined place (does not belong to either party)
state is shared between the entities in the collaboration
24
Collaborationcollaboration hospitalization { state Patient {} Nurse {} Doctor {} functionality(){}}
class Hospitalization { state class Patient {} class Nurse {} class Doctor {} functionality(){}}
Hospitalization
Patient
Nurse
Doctor
25
Collaboration
Hospitalization
Patient
Nurse
Doctor
Hospitalization
Patient
Nurse
Doctor
Person
Person
Person
26
Multiple concurrent collaborations
A person can play several roles in several collaborations…(e.g. of other domains)
Hospitalization
Patient
Nurse
Doctor
Person
Person Person
Hospitalization
Patient
Nurse
Doctor
Person
Person
27
Collaboration scope rules
Which i is found when accessed from A?
E
Bi
A
C
F
i
•Having three search paths may show to be to complex in practice
•Letters denote lookup order
Di
28
Collaboration scope rules
Since the object’s inheritance has precedence over the collaboration scope, accidentally intro introducing the field i (or method m) on an intrinsic object, breaks collaborations… Remember:
objects can be busy
HP K
29
Collaboration scoping rules
The same unfortunate effect also occurs when introducing fields and methods on an intrinsic, since a method in the role will overwrite it This may call for an explicit override keyword
as seen in C# and Beta? Such a keyword will limit the objects on which the
role can be applied, that may give rise to unnatural restrictions (for a dynamically typed language)
30
Accidental overwrites
The same applies for adding a method on the role, since calling through the role, the overwritten method is called, rather than the one on the intrinsic
31
Abstraction mechanisms
Since collaborations are just classes we can Aggregate collaborations
Public behavior serves as the collaborations outer interface (what can be done on the collaboration)
Specialize collaboration behavior Private/public behavior can be specialized, where private
behavior is usable only to the collaboration or its entities. Specialize collaboration roles
Since inner classes/roles are virtual they too can be specialized
Nest collaboration inside collaborations
32
class Person {
Inner i;
void makeInner() {
i = new self.Inner();
}
void foo() { i.foo(); }
class Inner { int foo(){return 1;} }
}
Virtual classes and multiple views Virtual classes may be problematic, in that
they “live longer” than a method invocation…Role R for Person {
class Inner {
int foo(){return 2;}
}
}
P p = new P() P p = new P() R r = new R(p)p.makeInner() r.makeInner()p.foo() p.foo()=> 1 => 2
33
Roles and collaborations
A role can be applied a collaboration Changes the public interface of the coll.
A role can contain a role Overwrites a role of the coll.
A role can contain a class Overwrites a class of the coll.
A role can contain a coll. Overwrites a coll. of the coll.
overwriting is not automatic but the effect of the previous slide
34
Roles and collaborations
A role can contain a role Converting a class to a role
The role must know for which class and instantiate this as its intrinsic object
A role can contain a class Converting a role to a class – but does it make
sense?? The class must somehow have the
same type as the role Can only perform consultation semantics rather than
delegation
… on mismatching types
35
Roles and collaborations
Constituent methods can be used for the same things Changes the role/class instantly – we are not
forced to call through the role Has additive behavior (several around methods
can be defined for the same method) Can more elegantly change deeply nested
classes/roles (e.g. a role C in a role B in a coll. A) An advice and a pointcut Or in the role R put a role A inside it have a role B inside
this have a role C
36
Collaborations in practice
If used heavily they make objects become mere holders of state (which may even be introduced) – reminds me of database programming
It may be a great way to organize aspects – especially when you have aspects for aspects since what the aspect touches is explicit
37
The End
38
Open questions…
39
Collaborations and real usage There are some practical issues (or is it just
me who is pedantic?) Collaborations needs be created
May make applications more memory hungry (this I’m not worried about)
Code is more tedious to write, since one cannot just allocate an object, but has to allocate a collaboration, a role and the object Object Teams and Caesar has made a within-construct
to ease this somewhat (hiding the fact that role and coll. is allocated). But only works if intrinsic type are distinct!
40
Collaborations and real usage If the collaboration should know about which
instances it contains, there needs be factory methods for each inner class/role and functionality for moving instances out of the collaboration These could be auto-generated by the compiler
e.g. by introducing subtypes of Intrinsic and Role so this behavior is not forced upon the programmer.
Should instantiation outside these factory methods then be forbidden?