1. Collaboration based Role-Oriented Programming Kasper B. Graversen

2. 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?

3. Today’s menu… Roles  dynamic specialization of object Collaborations  focus on processes

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  + 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  + Dynamic  + Multiplicity Account Role A Role B

6. Context and objects Inheritance  + Of the same type  + Late binding of self  + Methods are inherited  - 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 RARA Student Courses[]; Teacher weekhours; Person Calendar; 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. Original system 1st extension Teacher weekhours; Person Calendar; name; address; WageEarner salary; getSalary() BonusWage getSalary() 2nd extension

10. The difference between class and role inheritance Roles are dynamic and non-exclusive A B C Compile-time: A or AB or AC Distinct entities of a family A Run-time: A or AB or AC or ABC Context for entity A A B C

11. The difference between class and role inheritance Roles are dynamic and non-exclusive A BC Compile-time: A or AB or AC Distinct role entities of a family A Run-time: A or AB or AC or ABC Defines contexts B, C for context A A BC role subclass role for role

12. Roles adaptive behavior “Roles for roles” are applied where further specialization is needed. Course Administration System Student Courses[] Active selectCourse() Inactive Student- AsIncome amount University Economy System Person Calendar Name Address WageEarner salary getSalary() Room Calendar Course int points Roles are only used where dynamics occurs A new system easily adapts on top of the existing. Role constraint support Teacher weekhours

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; } 1 2 3

14. Constituents Needed in order to express flexible extensions on the same entry point or to overcome “reference hell” foo m()

15. Constituents Needed in order to express flexible extensions on the same entry point or to overcome “reference hell” foo m() logging

16. Constituents Needed in order to express flexible extensions on the same entry point or to overcome “reference hell” foo m() loggingcaching

17. Constituents Needed in order to express flexible extensions on the same entry point or to overcome “reference hell” foo m() loggingcaching ?

18. Constituents Needed in order to express flexible extensions on the same entry point or to overcome “pointer hell” foo m() logging caching constituent method binding m()

19. Collaborations

20. 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 reflected in the object-structure. Student Courses[] Active selectCourse() Inactive Student- AsIncome amount Person Calendar Name Address Teacher weekhours WageEarner salary getSalary()

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 reflected in the object-structure. Student Courses[] Active selectCourse() Inactive Student- AsIncome amount Person Calendar Name Address Teacher weekhours WageEarner salary getSalary()

22. 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

23. Collaboration collaboration hospitalization { state Patient {} Nurse {} Doctor {} functionality(){} } class Hospitalization { state class Patient {} class Nurse {} class Doctor {} functionality(){} } Hospitalization Patient Nurse Doctor

24. Collaboration Hospitalization Patient Nurse Doctor Hospitalization Patient Nurse Doctor Person

25. Multiple concurrent collaborations A person can play several roles in several collaborations… Hospitalization Patient Nurse Doctor Person Hospitalization Patient Nurse Doctor Person

26. Collaboration scope rules Which i is found when accessed from A? E BiBi A C F i Having three search paths may show to be to complex in practice Letters denote lookup order DiDi

27. Collaboration scope rules Since the object’s inheritance has precedence, accidentally intro introducing the field i on (or method m) an intrinsic object, breaks collaborations…  Remember: objects can be busy H P K

28. 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)

29. 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

30. 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() R r = new R(p) p.makeInner() r.makeInner() p.foo() => 1 => 2

31. 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.

32. 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

33. 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 addititive behaviour (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

34. The End

35. Open questions…

36. 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!

37. 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?