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