[otj-users] Develop Teams independent of base classes

[Stephan Herrmann]

> My question actually was, why you opted for the inheritance
> solution instead of type parameters.
Easy answer: at the time when the "connector" pattern was defined,
Java did not support type parameters ;-)

After some more thinking about this proposal I see 1 pro and 2 cons:
+1+ Yes, type parameters appear to be the "more natural way" 
    to configure the usage of a class/team.
-2- Writing "class MyRole playedBy T" with "<T extends ISomeBase>" 
    requires that role and base are not fully independent but they have
    to be developed with shared knowledge about the interface ISomeBase.
    By contrast, the inheritance-based connector better decouples
    the team definition from any base classes, because
    (a) no common interface needs to be defined and 
    (b) method bindings in the connector can perform renaming and
    signature adaptations.
-3- binding a role to a type parameter cannot be implemented in
    a Java-based language.
  Why?
  short answer: due to erasure
  long version:
    Declaring "class MyRole playedBy MyBase" guarantees that each
    instance of MyRole will be connected to an instance of MyBase.
    Transfer this to "playedBy T": 
    The role class has no idea what guarantee it is giving,
    but only the client instantiating the team will decide about
    the meaning of "T".

    Now consider two base classes MyBaseX, MyBaseY, both implementing
    ISomeBase, and the following instances.
        MyBaseX b= new MyBaseX();
        MyTeam<MyBaseY> t= new MyTeam<MyBaseY>();
    Now apply this in:
        t.activate(); // enable callin bindings
	b.someBaseMethod();
    If MyRole defines a callin binding regarding ISomeBase.someBaseMethod(),
    it is impossible to determine at runtime, whether or not the callin
    should fire or not.
    Note that the team instance "t" has _no_ runtime information about 
    "T" being "MyBaseY". Thus the team has every reason to actually 
    let the callin trigger, which results in wrong behavior, like creating
    a role MyRole<@t> bound to a base of type MyBaseX, which violates the
    original guarantee, because within "t" the role should be expanded to
    "class MyRole playedBy MyBaseY"!

    The lack of runtime information regarding T is due to Java's way
    of handling generics by erasure. 
    End of story :(


> Right, that would be a very interesting feature, since it allows Teams
> to be developed indepent from base classes, while still enabling them to
> use features of their potential base classes.
That's exactly, what we can do with inheritance-based connectors.


> [...] My view of Teams (or role models) is not only as a
> way to enhance modularity, but also as a (more or less) self-containing
> reuse unit.
agreed

> Since complete self-containment seems unrealistic, 
> describing the requirements for base classes by interfaces would be a
> nice compromise.
An abstract team with abstract roles with abstract methods specifies:
- We need a method of such-and-such name-and-signature. Sub-teams may
  choose to provide these methods by implementing or by callout binding.
I admit this not as good localized as when using an interface, so you 
could mix this style with using interfaces, but that's something I will
write directly to the Wiki ;-)

best,
Stephan