Messages and Collaborators

Messages and collaborators define how objects implement their behavior.

Objects here mean both objects and subjects, since subjects are actually objects.

Messages

An object has a set of messages. They are an interface or contract of the object.

A message can return either a value or nothing. A message cannot return an object. When a value is returned, a copy is provided; the semantic is the same as values such in C#. Changing a value outside an object does not affect the object state. The object state can be changed only by operations in messages implementations.

Access to an object to send a message is possible only by object access operation "->". Actually, the only operation with objects is sending messages. No direct access to object state, no properties or fields.

In message implementations, only collaborators can be used and the object state. Local objects and values also can be used. These restrictions limit the depth of calling chain (symptom from Java): there is a pattern that limits calling chain in a single expression like 2-3 methods. In Paml, an object can call only one level of its collaborators and local objects. But seems this idea cannot be resolved completely.

A message can have a set of parameters. Parameters are strictly objects (unlike return value of a message is strictly value). Argument types passing to a message may not match at all the parameter types. Arguments may be even values. The idea is that a parameter is a join point, so transformation can be applied to the parameter and converts argument to the parameter type. This is an abstraction to consider a term by a single name when the term may be defined like an identifier (which is a value) but a parameter is an object for the term. Actually this is a way to define overloads for a message.

Messages are not like low-level procedures, methods or functions. They are an abstraction that can be projected (via transformations) to different mechanisms like class methods, communicating channels or agent operations.

Collaborators

Collaborators are "helping" objects for an object, which are used by the object to implement its messages behavior. Collaborators are a kind of UML collaboration diagram.

A collaborator is instantiated by a policy, which is specified via transformation. Any object can be a collaborator. The instantiating policy is a property of collaborator, but not of object type.

Collaborators are a kind of inversion of control. An object just states that it has a set of collaborators to implement its behavior. How the collaborators are instantiated is not a responsibility of the object, but later by transformations.

Collaborators are abstraction for aggregates. Collaborator policies (via transformations) allow composing aggregates.

An object and its collaborators are not in relations like one-to-many. Such the relations are only defined on an object state as data. Collaborators literally collaborate with the object to implement its messages.

Code example