View source for OTJ Primer/Role Playing

Role Playing is a new relation between classes/objects introduced by [[OTJ|OT/J]]. Adding a role to an object has the effect of extending/specializing the existing object. Role playing is much more flexible than standard inheritance between classes.

[[Image:RolePlaying.png]]

==Class-level Binding==
At class level you simply write ({{otjld|2|.1}}):

<source lang="otj">public class Employee playedBy Person { /* details omitted */ }</source>
{{Tip|Try this example|
If you want to try this example, two requisites must be met: a class Person must already exist, and the declaration of Employee must be nested within a team class (see also [[OTJ_Primer/Role_Containment]]):
<source lang="otj">public team class Company { public class Employee playedBy Person {} }</source>}}


The above declaration has the effect that each runtime instance of Employee will be associated to a corresponding instance of Person. The compiler statically guarantees that there will never be an Employee instance without an associated Person instance. E.g., the default constructor for a bound role like Employee requires a non-null Person argument so you can write ({{otjld|2|.4.1}}):

<source lang="otj">Person joe = new Person("Joe");
Employee joeProgrammer = new Employee(joe);</source>
{{Tip|Try this example|
You may try the above snippet within a method of team class Company.
When doing so you'll actually see a compiler warning. Can you figure out what is the issue and how the snippet can still be improved? If the warning message by itself is not clear you can always seek advice by using the "[http://help.eclipse.org/topic/org.eclipse.objectteams.otdt.doc/guide/compilation.html Go to Language Definition]" action within the [[Object_Teams_Development_Tooling|OTDT]].}}

The syntax of OT/J does not allow direct access to the '''base''' link from a role instance to its base instance, but such access is controlled using '''callout''' method bindings, see next.

==Method-level Bindings==

===Callout===
Using a callout method binding a role can declare that it accepts messages by a certain name and that it will '''forward''' these messages to the associated base instance. We say a role '''acquires''' a base method ({{otjld|3|}}).

[[Image:CalloutGetName.png|300px]]

Several syntactic options exist for callout method bindings:
<source lang="otj">// separate declaration and binding:
abstract public String getName();
getName -> getName;

// short-hand declaration-and-binding:
String getName() -> String getName();</source>

A callout method binding may apply the following adaptations:
* The given base method may be made available using a different name, e.g.,
:<source lang="otj">getRealName -> getName;</source>
* Parameters may be re-mapped ({{otjld|3|.2}}), e.g.:
<dl><dd><source lang="otj">char[] getName(boolean useFirstName, boolean useTitle) -> String getName(boolean title, boolean firstName)
    with {  useFirstName -> firstName, useTitle -> title, result <- result.toCharArray() }</source>
</dl>

===Callin===
A role may also declare callin method bindings, which define message dispatch in the opposite direction compared to callout: a message sent to a base object can be '''intercepted''' by a callin binding, which redirects the call to the role instance ({{otjld|4|}}).

[[Image:CallinGetPhoneNo.png|300px]]

A basic callin binding looks like this:
<source lang="otj">getOfficePhoneNo <- replace getPhoneNo;</source>

Callin bindings can be fine-tuned like this:
* Chose between '''before''', '''after''' and '''replace''' bindings. The former two variants are purely additive - meaning the base method is still executed, whereas the latter variant corresponds to overriding ({{otjld|4|.2}}).
* Use signatures to discrimitate between overloaded methods.
* Use parameter mappings (see callout above) to adjust signatures ({{otjld|4|.4}}).
* Use labels to refer to callin bindings ({{otjld|4|.1.e}}) for
** overriding an inherited callin binding
** declaring precedence among several callin bindings to the same base method ({{otjld|4|.8}}).

===True Delegation===
Just by combining callout and callin method bindings the effect of true delegation is obtained, meaning that during a delegated call, self-calls are still dispatched to the original object, here: the role.

[[Image:DelegationGetContactData.png|320px]]

No new syntax other than callout and callin method bindings is required to achieve true delegation.

==Comparing Role-Playing and Inheritance==

The above implies that the '''playedBy''' relation is very similar to '''inheritance''':
* just like with inheritance, a role may '''acquire''' methods from its base
:* unlike inheritance, such acquisition must be declared individually and can adjust mismatches
* just like with inheritance, a role may '''override''' methods from its base
:* unlike inheritance, such overriding must be declared individually and can adjust mismatches
* just like with inheritance, acquisition and overriding can be combined for the '''template-method''' pattern.

However, a role-playing relationship has these two properties that are not supported by inheritance:
* role-playing is '''dynamic''' in that roles can come and go at any point during the life-cycle of a base object
* role-playing supports '''multiple independent specializations''' because multiple role instances can be attached to the same base instance.

==Moving on==
The explanation of role playing given so far raises two essential questions:
* if multiple roles are attached to the same base instance, how is the "correct" role selected during callin interception?
* how can callin-interception be fine-tuned to apply in specific situations only?

For answering these questions, the picture has to be expanded to include also '''[[../Role_Containment|teams]]'''.


[[Category:Object Teams]]