next up previous
Next: Evolving Collaborative Behavior Up: Related Work Previous: Related Work

Evolving Object Interfaces and Behavior

Perspectives [6] were among the earliest proposals for varying the interface of an object. Software components are represented as a network of nodes. The attributes of a node are grouped into perspectives, each providing a different view of the entity. To access a particular attribute of an object, one must specify the perspective along with the object. Views [20] present another approach to partitioning an object interface. As with perspectives, the required view must be explicitly paired with an object to access an attribute or invoke a method of the object. Both perspectives and views require clients to know about the interface subset partitioning, thus violating encapsulation. Arapis [1] proposed the notion of contexts (we will refer to these as Arapis-contexts) to represent the roles of an object. As with perspectives and views, the client of an object must specifically state the method of a particular Arapis-context to be invoked. The mode concept of Taivalsaari partitions the implementations of an interface, rather than the interfaces of an object [23]. When an object receives a message, the implementation triggered depends on the mode or state of the object. As opposed to roles and views, clients need not be aware of the current mode at the call site.

Each of these proposals is based on changing behavior for a single object.

Karl Lieberherr
Tue Jan 21 09:24:10 EST 1997