Content deleted Content added
→Distinguishing traits of DCI: added references. |
|||
Line 34:
==Distinguishing traits of DCI==
DCI limits all permissible networks of communicating objects to networks that share common topologies, one for each use case<ref name="Working with objects">{{cite web |author1=Trygve Reenskaug |author2=James O. Coplien |title=Working with objects - in computer and mind |url=https://fulloo.info/Documents/CommSenseCurrentDraft.pdf}}</ref><ref name="DCI Paradigm" />. Such networks are explicit in the interactions between DCI Roles, whereas in classical object orientation they are emergent. A Role is a node in such a topology; it is a partial classification of the behaviors of all objects that can occupy this node. The topology is a description of the run-time structure of a system<ref name="Common sense">{{cite web |last1=Reenskaug |first1=Trygve |title=The Common Sense of Object Oriented Programming |url=https://fulloo.info/Documents/200904commonsense.pdf}}</ref>.▼
▲DCI limits all permissible networks of communicating objects to networks that share common topologies, one for each use case. Such networks are explicit in the interactions between DCI Roles, whereas in classical object orientation they are emergent. A Role is a node in such a topology; it is a partial classification of the behaviors of all objects that can occupy this node. The topology is a description of the run-time structure of a system.
An object-oriented program is a complex and dynamic network of objects, in the same sense that relationships between real-world objects are complex and dynamic. Consider a waiter at a restaurant. The waiter himself is a complex object that can be viewed in many ways: as my Waiter (e.g., who describes tonight's menu and takes my order), as an Employee of the restaurant (with a certain salary and working hours), and as a Person in the restaurant (which has an occupancy limitation of 150 people). If a Waiter class was written to capture the real-world essence of Waiters (which is what object orientation is really all about), it would have to be very complex to support all of these perspectives.
In DCI these different views are factored into Roles. At run time, the Role is the identity of the object<ref name="Glossary" />. During the enactment of a [[use case]] (like ''Serve the Wine'') the Role ''Waiter'' unambiguously identifies a single object at any given time<ref name="Execution model" />. You might argue there may be several Waiters at the table. However, they are likely to differ in their responsibilities within a [[use case]], such as are found in Role names HeadWaiter and Busboy. Even if their responsibilities are identical, they would still be described as Waiter-1 and Waiter-2, or as individual (named) elements of a Waiter vector, if someone intended to write software for them. So a Role like HeadWaiter becomes the identifier, the handle, by which objects refer to each other in a [[use case]].
DCI recognizes the Waiter as an object rather than, say, a composition of an Employee part, a Waiter part and a Person part. The object has its own identity independent of the [[use case]]; this is the Data facet of DCI. Roles are aliased names for their objects but are never separate objects themselves; that would cause [[schizophrenia (object-oriented programming)|self schizophrenia]]. In this sense, every Waiter is a ''homo sapiens''. This is the Waiter's rudimentary what-the-system-is part. The object has many possible identities depending on the [[use case]] it is involved in; this surfaces in the Role identities that form part of the Interaction facet of DCI. These are the (usually more interesting) what-the-system-does part. However, in DCI, there is only a single ''object'' that carries both these perspectives at run time. These perspectives may be grouped differently at coding time. The code is dominated by the [[use case]] structure, which cuts across the objects, and which also is part of the Interaction facet of DCI.
DCI allows an object to take on one or more Roles during a [[use case]] enactment. In other words, an object is re-bound to Role identifiers on each [[use case]] enactment<ref name="Execution model" />. These Roles infer an interface, referred to as the ''Role type.'' Each object is "re-cast" (in the theatrical sense) anew on every [[use case]]. Though a Role is bound only to a single object, an object may play several Roles. For example, a HeadWaiter may be involved in a [[use case]] to count all the occupants of the restaurant during a fire inspection, and will play the Person Role as well as the HeadWaiter Role. The single object supports the behaviors of both Roles necessary to carry out the [[use case]].
In summary, DCI architectures tend to be characterized by the following properties<ref name="Artima" /><ref name="Common sense" />:
* The Data model reflects the ___domain structure rather than partitions of its behavior;
* Objects dynamically take on Roles during [[use case]] enactments;
| |||