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?