Content deleted Content added
→Distinguishing traits of DCI: added references. |
m →Execution model: added references. |
||
Line 53:
==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]]<ref name="DCI Paradigm" />. 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.▼
▲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<ref name="Execution model" />.
As described above, each Context provides a design scope for the Roles that participate in the [[use case]] enactment. It is the job of the Context to assign objects to play these Roles<ref name="Glossary" />.
# The Context first finds the objects that are to take part in this [[use case]] enactment. These objects may be anywhere in the environment, or in a database, or created on the fly; DCI does not restrict these objects. Within a Context there is at most one instance playing any given Role at any given time.
# Second, the Context assigns a single object to play each of its Roles (though a single object often plays multiple Roles in a single Context). In strongly dynamic languages (Ruby, Python) the Context [[dependency injection|''injects'']] the Role methods into the object. In most dynamic languages, any extant object can be asked to play any Role at any time (though some object-Role combinations may of course make no sense; nonsense combinations of objects and Roles would lead to <code>MESSAGE NOT UNDERSTOOD</code> at run time if the Role method were invoked.) In more statically typed languages (Scala, C++) there has to have been some prior arrangement for the object to support the Role methods. For example, Scala creates an anonymous class that combines the rudimentary logic of a ___domain class with the [[use case]] logic of the [[Trait (computer science)|trait]] used to implement a Role; Roles are effectively assigned to ___domain objects when they are instantiated.
| |||