all news
RSS feed»Programming with roles and beyond.«
Why Object Teams?
Team spirit for objects
Building complex systems from isolated objects often yields poor
structure which readily decays during system evolution.
Objects should team-up in order to co-operate and jointly
deliver complex behaviors.
Objects play specific roles within a given Team.
Context based dispatch
Object behavior is controled by the currently active
context of execution. Contexts are reified into
Team instances, which may be used to mediate
between roles and maintain state of the collaboration.
Modules larger than classes
On the road to re-use of modules larger than classes two
approaches compete: frameworks and components.
For many applications white box frameworks are too fragile and
black box components to rigid.
Object Teams provide a middle road which balances
encapsulation and adaptability.
Key Features of Object Teams
-
Weaving of aspect code into existing classes (no source code needed).
-
Teams are modules that encapsulate the interaction of a set of role objects.
-
Teams can be type-checked in a modular way.
-
Roles are automatically managed by their enclosing Team instance.
-
-
Teams can be refined using inheritance.
-
Collective refinement of role classes.
-
Team refinement realizes type-safe covariance of role signatures.
-
-
Teams are instantiable first class entities.
-
Teams are aspects that can be activated/deactivated at run-time.
-
Roles may refer to their enclosing Team.
-
-
Explicit connectors bind an abstract Team definition to a base package.
-
Binding happens a-posteriori, i.e., no modification in the base package is required.
-
Team binding is specified in a declarative style.
-
Bindings may specify different kinds of adaptations.
-
-
Object Teams require a minimal number of new language constructs to be learned for a maximum of modularity and composability.
