Roles Before Objects

Author

Doug Lea (dl@g.oswego.edu).

Last updated on Sun Jan 29 08:32:26 1995

Context

``Roles before objects'' is the first of a set of patterns for organizing activities that separate object-independent from object-dependent matters, in the interest of postponing or avoiding object-level commitments during development and/or execution. It is particularly well-suited to the development of open distributed object systems in which object-independent descriptions take the form of public interfaces. (See below for more guidance about when to use this pattern.)

Problem

How do you encapsulate features, services and responsibilities without knowing, caring about, committing to, revealing, or representing the particular objects (or their classes) that will possess or provide them?

Examples

Forces

  1. Early in development, it is often easier and more productive to deal with services, interfaces, and protocols without committing to the existence of particular objects and classes that support them.
  2. If you do commit too early to the forms of objects (and their classes), you can get stuck with suboptimal (or just plain bad) designs, and will have to perform expensive and disruptive rework. It is better to avoid this via scaffolding that allows you to progressively commit to object-level computational matters without backtracking, while at the same time allowing for the implementation of default versions of some or all features, in order to prototype and evaluate the design without committing to its details.
  3. The same kinds of issues can appear even during execution. If messages are tied to particular objects, then you cannot, for example, replace a faulty component with a fixed one without doing a lot of rewiring. In some environments (notably CORBA), capabilities along these lines are even mandated. Many aspects of CORBA systems and services cannot be described at all at the level of classes and objects.

Solution

The solution is to add a level of abstraction to object-based constructs, the notion of a role. A role is an instance of an encapsulated set of properties and behavior, but is described and used in a way that is totally independent of the object(s) that may implement it.

This definition is just a technical narrowing of the most common everyday sense of the word role. For example, we can talk about the role of Hamlet in a particular performance, without reference to the actor(s) playing this role. The decision about who plays this role is a separate ``casting'' decision. Normally we'd like to pick the single actor providing the highest ``quality of service''. But we would also like the freedom to swap in a designated ``second'' if the original actor gets sick, or perhaps even to use two children, one on the other's shoulders and together dressed to look like a single adult actor.

This notion of a role generalizes common OO techniques involving abstract classes and related constructs, but elevates them to first-class status. (Thus, for example, abstract classes are special-case techniques in role-based development.) In particular, there is a many-to-many relation between roles and objects. One role may be implemented by either one object or by several otherwise unrelated objects working together. Each may implement a subset of operations, or redundantly implement all of them. For example, an OfficeManager role might be implemented using:

Conversely, one implementation object may support several otherwise unrelated interfaces concurrently, or different interfaces across time. For example, a Person object might play the roles (hence ``export'' the interfaces) of:

A good way to think about such relationships is to treat roles as channels to objects, where each role supplies particular clients with a coherent view of a set of capabilities:

Applicability

Design Steps

Once you have decided to adopt a role-based scheme, you need to delve into the details. The following entries describe the two main facets:

Background

There have been quite a few attempts recently to integrate various conceptualizations of roles with mainstream OO development. From another view, roles have emerged as a way of making sense of and extending common techniques for separating interfaces from implementations. The current patterns describe a variant associated with the role-based specification framework described in our PSL paper. The paper includes some brief surveys, comparisons, and references to related work, including: