Content deleted Content added
Fox Elvoret (talk | contribs) |
Fox Elvoret (talk | contribs) |
||
Line 30:
The interaction is "what the system ''does''." The interaction is implemented as Roles which are played by objects at run time. These objects combine the state and methods of a data (___domain) object with methods (but no state, as Roles are stateless) from one or more Roles. In good DCI style, a Role addresses another object only in terms of its (methodless) Role. There is a special Role called <code>self</code> which binds to the object playing the current Role. Code within a Role method may invoke a method on <code>self</code> and thereby invoke a method of the data part of the current object. One curious aspect of DCI is that these bindings are guaranteed to be in place only at run time (using a variety of approaches and conventions; [[C++ template]]s can be used to guarantee that the bindings will succeed). This means that interactions, the Role methods, are ''generic''. In fact, some DCI implementations use generics or templates for Roles.
A Role is a stateless programming construct that corresponds to the end user's mental model of some entity in the system. A Role represents a collection of responsibilities. Whereas vernacular object-oriented programming speaks of objects or classes as
In the above money transfer use case, for example, the Role methods in the SourceAccount and DestinationAccount enact the actual transfer.
| |||