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

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

3. 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. 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. 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. 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. 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. 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. 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 system 1st extension Teacher weekhours; Person Calendar; name; address; WageEarner salary; getSalary() BonusWage getSalary() 2nd extension

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

11. 11 The difference between class and role inheritance Roles are dynamic and non-exclusive A BC Compile-time: A or B or C 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. 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. 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. 14 Constituents Needed in order to express flexible extensions on the same entry point or to overcome “reference hell” foo m()

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

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

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

18. 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. 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. 20 Collaborations

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

23. 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. 24 Collaboration collaboration hospitalization { state Patient {} Nurse {} Doctor {} functionality(){} } class Hospitalization { state class Patient {} class Nurse {} class Doctor {} functionality(){} } Hospitalization Patient Nurse Doctor

25. 25 Collaboration Hospitalization Patient Nurse Doctor Hospitalization Patient Nurse Doctor Person

26. 26 Multiple concurrent collaborations A person can play several roles in several collaborations…(e.g. of other domains) Hospitalization Patient Nurse Doctor Person Hospitalization Patient Nurse Doctor Person

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

28. 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 H P K

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

33. 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. 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. 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. 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. 37 The End

38. 38 Open questions…

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