Data, context, and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects. Its goals are: To improve the readability of object-oriented code by giving system behavior first-class status; To cleanly separate code for rapidly changing system behavior (what a system does) versus slowly changing domain knowledge (what a system is), instead of combining both in one class interface; To help software developers reason about system-level state and behavior instead of only object state and behavior; To support an object style of thinking that is close to programmers' mental models, rather than the class style of thinking that overshadowed object thinking early in the history of object-oriented programming languages. The paradigm separates the domain model (data) from use cases (context) and Roles that objects play (interaction). DCI is complementary to model–view–controller (MVC). MVC as a pattern language is still used to separate the data and its processing from presentation.
Description
Data The data remains "what the system is." The data part of the DCI architecture is its (relatively) static data model with relations. The data design is usually coded up as conventional classes that represent the basic domain structure of the system. These classes are barely smart data, and they explicitly lack the functionality that is peculiar to support of any particular use case. These classes commonly encapsulate the physical storage of the data. These data implement an information structure that comes from the mental model of end users, domain experts, programmers, and other people in the system. They may correspond closely to the model objects of MVC.
An example of a data object could be a bank account. Its interface would have basic operations for increasing and decreasing the balance and for inquiring about the current balance. The interface would likely not offer operations that involve transactions, or which in any way involve other objects or any user interaction. So, for example, while a bank account may offer a primitive for increasing the balance, it would have no method called deposit. Such operations belong instead in the interaction part of DCI.
Data objects are instances of classes that might come from domain-driven design, and such classes might use subtyping relationships to organize domain data. Though it reduces to classes in the end, DCI reflects a computational model dominated by object thinking rather than class thinking. Therefore, when thinking "data" in DCI, it means thinking more about the instances at run time than about the classes from which they were instantiated.
Context The context is the class (or its instance) whose code includes the Roles for a given algorithm, scenario, or use case, as well as the code to map these Roles into objects at run time and to enact the use case. Each Role is bound to exactly one object during any given use case enactment; however, a single object may simultaneously play several Roles. A context is instantiated at the beginning of the enactment of an algorithm, scenario, or use case. In summary, a context comprises use cases and algorithms in which data objects are used through specific Roles.
Each context represents one or more use cases. A context object is instantiated for each enactment of a use case for which it is responsible. Its main job is to identify the objects that will participate in the use case and to assign them to play the Roles which carry out the use case through their responsibilities. A Role may comprise methods, and each method is some small part of the logic of an algorithm implementing a use case. Role methods run in the context of an object that is selected by the context to play that Role for the current use case enactment. The Role-to-object bindings that take place in a context can be contrasted with the polymorphism of vernacular object-oriented programming. The overall business functionality is the sum of complex, dynamic networks of methods decentralized in multiple contexts and their Roles.
Each context is a scope that includes identifiers that correspond to its Roles. Any Role executing within that context can refer to the other Roles in that context through these identifiers. These identifiers have come to be called RoleMethods. At use case enactment time, each and every one of these identifiers becomes bound to an object playing the corresponding Role for this context.
An example of a context could be a wire transfer between two accounts, where data models (the banking accounts) are used through Roles named SourceAccount and DestinationAccount.
Interaction 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 self which binds to the object playing the current Role. Code within a Role method may invoke a method on self 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++ templates 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 a multiplicity of responsibilities, DCI ascribes them to Roles. An object participating in a use case has responsibilities: those that it takes on as a result of playing a particular Role. Most modern programming languages have a way to express Roles, and to express the injection of Role methods into objects, and implementation techniques vary depending on the language. The injection can be fully dynamic at run-time in languages like Ruby and Python; it is more static in languages like Smalltalk-Squeak, Scala and C++. The Qi4j programming environment offers a way to express Role method injection into Java objects.Qi4j framework Java 8 default method on interfaces can be used to implement Roles in a typesafe way.
In the above money transfer use case, for example, the Role methods in the SourceAccount and DestinationAccount enact the actual transfer.
Distinguishing traits of DCI 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. During the enactment of a use case (like Serve the Wine) the Role Waiter unambiguously identifies a single object at any given time. 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 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. 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: The Data model reflects the domain structure rather than partitions of its behavior; Objects dynamically take on Roles during use case enactments; Every Role of a use case is played by an object determined by the Context at the start of the use case enactment; The network of Interactions between Roles in the code (i.e., at coding time) is the same as the corresponding network of objects at run time; These networks are potentially re-created on every use case enactment; Roles come in and out of scope with use case lifetimes, but objects that may play these Roles may persist across multiple use case lifetimes and may potentially play many Roles over their own lifetime.
Execution model DCI can be thought of as an event-driven programming paradigm, where some event (as a human gesture in a model-view-controller (MVC) architecture) triggers a use case. The use case can be short-lived or long-lived. The events are called triggers, and they are handled in the environment in which DCI is embedded. This environment may be the controller of a conventional MVC architecture or any other system-level code.
The trigger causes the environment to instantiate a context object. The type of object is chosen according to the kind of use case that will ensue, based on information about the trigger or the system state or both. For example, a cash machine might have separate Context classes for money transfer, withdrawal, deposit, balance inquiry, and so forth. Once the environment instantiates the Context object, it invokes its trigger method to start the use case enactment.