Data, Context, and Interaction
Encyclopedia
Data, context and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects
. Its goals are:
The paradigm separates the domain model
(data) from use case
s (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.
DCI was invented by Trygve Reenskaug
, also the inventor of MVC. The current formulation of DCI is mostly the work of Reenskaug and James O. Coplien.
Context
Interaction
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 we wrote a Waiter class 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 we factor these different views 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 we find in role names HeadWaiter and Busboy. Even if their responsibilities are identical, we would still describe them as Waiter-1 and Waiter-2, or as individual (named) elements of a Waiter vector, if we 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 (or, if we admit robots, is an animate object capable of some basic vocal and motor operations). 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:
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 has been 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.
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.
Implementation techniques differ across programming languages. What is common to most approaches is that Roles are represented by such constructs as generics, templates, classes, or traits. Code for the basic domain logic is implemented separately, following conventional object-oriented practice and most commonly using classes. Each Role's code is injected into the domain object that will play it during the use case
enactment. To implement roles
, method injection is usually needed. Traits are one common programming language technique to support method injection. Some languages, such as Scala, have native support for traits, while other languages (e.g., Ruby
and Python
) allow run time injection of methods. In Java
, pre-compiler tricks based on annotations are needed to support DCI.
Several example implementations exist: Smalltalk
/Squeak
, C++
, C#, Ruby
, JavaScript
, Python
, Qi4J (Java
), Scala, Perl
, and PHP
.
Trygve felt it was important to create program structures about which one can reason, and started socializing these ideas as early as 2000. By 2006 he had a working design model, and his discovery in 2008 of Schärli's work on Traits provided the keystone that would provide natural programming language expression of these ideas. He prototyped the ideas in the Baby programming environment, written in Squeak. Jim Coplien joined Trygve on this effort in about 2007 and by mid-2008 had a prototype running in C++. Steen Lehmann, Rickard Öberg and Niclas Hedhman accelerated the adaptation of these ideas to Ruby
and Java
over the next year or so with the Qi4j framework. Many additional language adaptations followed a session at the JaOO conference in Denmark in September 2008.
Many key advances in the past twenty years of object-orientation exhibit components of DCI. While no one of them fully provides the DCI computational model, the overlap suggests that the problems addressed by DCI are longstanding and fundamental.
Object (computer science)
In computer science, an object is any entity that can be manipulated by the commands of a programming language, such as a value, variable, function, or data structure...
. Its goals are:
- To improve the readability of object-orientedObject-oriented programmingObject-oriented programming is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction,...
code by giving system behavior first-class status; - To cleanly separate code for rapidly changing system behavior (what the system does) from code for slowly changing domain knowledge (what the 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 peoples' 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
Domain model
A domain model in problem solving and software engineering can be thought of as a conceptual model of a domain of interest which describes the various entities, their attributes, roles and relationships, plus the constraints that govern the integrity of the model elements comprising that problem...
(data) from use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
s (context) and roles that objects
Object (computer science)
In computer science, an object is any entity that can be manipulated by the commands of a programming language, such as a value, variable, function, or data structure...
play (interaction). DCI is complementary to model–view–controller (MVC). MVC as a pattern language
Pattern language
A pattern language, a term coined by architect Christopher Alexander, is a structured method of describing good design practices within a field of expertise. Advocates of this design approach claim that ordinary people of ordinary intelligence can use it to successfully solve very large, complex...
is still used to separate the data and its processing from presentation.
DCI was invented by Trygve Reenskaug
Trygve Reenskaug
Trygve Mikkjel Heyerdahl Reenskaug is a Norwegian computer scientist and professor emeritus of the University of Oslo. He formulated the model-view-controller pattern for Graphic User Interface software design in 1979 while visiting the Xerox Palo Alto Research Center...
, also the inventor of MVC. The current formulation of DCI is mostly the work of Reenskaug and James O. Coplien.
Description
Data- The data are "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 caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
, as well as the code to map these roles into objects at run time and to enact the use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
. 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 caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
. In summary, a Context comprises use cases and algorithmAlgorithmIn mathematics and computer science, an algorithm is an effective method expressed as a finite list of well-defined instructions for calculating a function. Algorithms are used for calculation, data processing, and automated reasoning...
s 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 caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
and to assign them to play the Roles which carry out the use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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 caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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 methodless roles. 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
selfwhich binds to the object playing the current Role. Code within a Role method may invoke a method onselfand 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 the loci of responsibilities, DCI ascribes them to Roles. An object participating in a use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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 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.
- In the above money transfer use case, for example, The role methods in the SourceAccount and DestinationAccount enact the actual transfer.
Distinguishing Characteristics 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 we wrote a Waiter class 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 we factor these different views into Roles. At run time, the Role is the identity of the object. During the enactment of a use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
(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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
, such as we find in role names HeadWaiter and Busboy. Even if their responsibilities are identical, we would still describe them as Waiter-1 and Waiter-2, or as individual (named) elements of a Waiter vector, if we 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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
.
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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
; 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
Schizophrenia (object-oriented programming)
Object schizophrenia or self schizophrenia is a complication arising from delegation and related techniques in object-oriented programming.An object can be defined as a computing concept combining data and behavior, and having an identity. Objects are typically built on class systems...
. In this sense, every Waiter is a homo sapiens (or, if we admit robots, is an animate object capable of some basic vocal and motor operations). This is the Waiter's rudimentary what-the-system-is part. The object has many possible identities depending on the use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
enactment. In other words, an object is re-bound to Role identifiers on each use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
. 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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
.
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 caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
enactments; - Every Role of a use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
is played by an object determined by the Context at the start of the use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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 caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
enactment; - Roles come in and out of scope with use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
lifetimes, but objects that may play these Roles may persist across multiple use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
lifetimes and may potentially play many Roles over their own lifetime.
Execution Model
DCI can be thought of as an event-driven paradigm, where some event (as a human gesture in an MVCModel-view-controller
Model–view–controller is a software architecture, currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" from the user interface , permitting independent development, testing and maintenance of each .Model View Controller...
architecture) triggers a use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
. The use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
can be short-lived or long-lived. The events are called triggers, and they are handled in the environment in which DCI has been embedded. This environment may be the Controller of a conventional MVC
Model-view-controller
Model–view–controller is a software architecture, currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" from the user interface , permitting independent development, testing and maintenance of each .Model View Controller...
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
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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.
As described above, each Context provides a design scope for the Roles that participate in the use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
enactment. It is the job of the Context to assign objects to play these Roles.
- The Context first finds the objects that are to take part in this use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
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 injectsDependency injectionDependency injection is a design pattern in object-oriented computer programming whose purpose is to improve testability of, and simplify deployment of components in very large software systems....
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 toMESSAGE NOT UNDERSTOODat 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 caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
logic of the trait used to implement a Role; Roles are effectively assigned to domain objects when they are instantiated. - Third, the Context invokes a Role method on the first object to take part in the use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
. - From that point forward, Roles invoke each others' methods to carry out the use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
. A role method may invoke a method onselfwhich in fact is handled by the object currently playing the Role. This is how Roles invoke the rudimentary data operations of the objects currently playing them at the time.
Implementing DCI
DCI depends on a design process that separates use cases from the data model. The data model is often based on an informal domain analysis. The roles that characterize the end-user's model of system functionality come from the use cases. One approach to overall DCI design is Lean Architecture described in a book of the same name.Implementation techniques differ across programming languages. What is common to most approaches is that Roles are represented by such constructs as generics, templates, classes, or traits. Code for the basic domain logic is implemented separately, following conventional object-oriented practice and most commonly using classes. Each Role's code is injected into the domain object that will play it during the use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
enactment. To implement roles
Role-Oriented Programming
Role-oriented programming is a form of computer programming aimed at expressing things in terms which are analogous to human conceptual understanding of the world. This should make programs easier to understand and maintain....
, method injection is usually needed. Traits are one common programming language technique to support method injection. Some languages, such as Scala, have native support for traits, while other languages (e.g., Ruby
Ruby (programming language)
Ruby is a dynamic, reflective, general-purpose object-oriented programming language that combines syntax inspired by Perl with Smalltalk-like features. Ruby originated in Japan during the mid-1990s and was first developed and designed by Yukihiro "Matz" Matsumoto...
and Python
Python (programming language)
Python is a general-purpose, high-level programming language whose design philosophy emphasizes code readability. Python claims to "[combine] remarkable power with very clear syntax", and its standard library is large and comprehensive...
) allow run time injection of methods. In Java
Java (programming language)
Java is a programming language originally developed by James Gosling at Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities...
, pre-compiler tricks based on annotations are needed to support DCI.
Several example implementations exist: Smalltalk
Smalltalk
Smalltalk is an object-oriented, dynamically typed, reflective programming language. Smalltalk was created as the language to underpin the "new world" of computing exemplified by "human–computer symbiosis." It was designed and created in part for educational use, more so for constructionist...
/Squeak
Squeak
The Squeak programming language is a Smalltalk implementation. It is object-oriented, class-based and reflective.It was derived directly from Smalltalk-80 by a group at Apple Computer that included some of the original Smalltalk-80 developers...
, C++
C++
C++ is a statically typed, free-form, multi-paradigm, compiled, general-purpose programming language. It is regarded as an intermediate-level language, as it comprises a combination of both high-level and low-level language features. It was developed by Bjarne Stroustrup starting in 1979 at Bell...
, C#, Ruby
Ruby (programming language)
Ruby is a dynamic, reflective, general-purpose object-oriented programming language that combines syntax inspired by Perl with Smalltalk-like features. Ruby originated in Japan during the mid-1990s and was first developed and designed by Yukihiro "Matz" Matsumoto...
, JavaScript
JavaScript
JavaScript is a prototype-based scripting language that is dynamic, weakly typed and has first-class functions. It is a multi-paradigm language, supporting object-oriented, imperative, and functional programming styles....
, Python
Python (programming language)
Python is a general-purpose, high-level programming language whose design philosophy emphasizes code readability. Python claims to "[combine] remarkable power with very clear syntax", and its standard library is large and comprehensive...
, Qi4J (Java
Java (programming language)
Java is a programming language originally developed by James Gosling at Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities...
), Scala, Perl
Perl
Perl is a high-level, general-purpose, interpreted, dynamic programming language. Perl was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier. Since then, it has undergone many changes and revisions and become widely popular...
, and PHP
PHP
PHP is a general-purpose server-side scripting language originally designed for web development to produce dynamic web pages. For this purpose, PHP code is embedded into the HTML source document and interpreted by a web server with a PHP processor module, which generates the web page document...
.
History
DCI arose largely as an outgrowth of Trygve Reenskaug's work on role-based modeling. Trygve had long recognized that Roles played a central part in the way we think about objects, and that the class-based progression of programming language technology took away much of the motivation to think about the objects in a program. That in turn made it difficult to reason about the program at run time. Further, the fact that object-oriented programming languages offered only classes to express program logic left the programmer at the mercy of the structural layout of the data to delineate behavior, which is unnatural compared with a delineating behavior on Role boundaries. This in turn made program behavior more difficult to reason about than in, say, a procedural program in FORTRAN.Trygve felt it was important to create program structures about which one can reason, and started socializing these ideas as early as 2000. By 2006 he had a working design model, and his discovery in 2008 of Schärli's work on Traits provided the keystone that would provide natural programming language expression of these ideas. He prototyped the ideas in the Baby programming environment, written in Squeak. Jim Coplien joined Trygve on this effort in about 2007 and by mid-2008 had a prototype running in C++. Steen Lehmann, Rickard Öberg and Niclas Hedhman accelerated the adaptation of these ideas to Ruby
Ruby (programming language)
Ruby is a dynamic, reflective, general-purpose object-oriented programming language that combines syntax inspired by Perl with Smalltalk-like features. Ruby originated in Japan during the mid-1990s and was first developed and designed by Yukihiro "Matz" Matsumoto...
and Java
Java (programming language)
Java is a programming language originally developed by James Gosling at Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities...
over the next year or so with the Qi4j framework. Many additional language adaptations followed a session at the JaOO conference in Denmark in September 2008.
Many key advances in the past twenty years of object-orientation exhibit components of DCI. While no one of them fully provides the DCI computational model, the overlap suggests that the problems addressed by DCI are longstanding and fundamental.
- Mix-insMixinIn object-oriented programming languages, a mixin is a class that provides a certain functionality to be inherited or just reused by a subclass, while not meant for instantiation , Mixins are synonymous functionally with abstract base classes...
were a way of encapsulating code for specific what-the-system-does functionality in closed form; however, there is no consistent mechanism to link multiple mix-ins into a unit at the level of a use caseUse caseIn software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
. Mix-ins are very close to the concept of Role in DCI. - Multiple dispatchMultiple dispatchMultiple dispatch or multimethods or function overloading is the feature of some object-oriented programming languages in which a function or method can be dynamically dispatched based on the run time type of more than one of its arguments...
was an early attempt to more fully separate an algorithm from the objects that were involved in its execution, but it lacked DCI's separation of common recurring algorithms from the code fragments that could individually be localized to individual objects. DCI conceptually leads to broader re-use of a single algorithm in closed form across many sets of objects of widely heterogeneous types. DCI's Context object acts like an explicit, intelligence dispatcher that is analogous to the dispatching mechanisms of languages with multiple dispatch. - True object-oriented programming languages like selfSelf programming languageSelf is an object-oriented programming language based on the concept of prototypes. Essentially an extreme dialect of Smalltalk, it was used mainly as an experimental test system for language design in the 1980s and 1990s. In 2006, Self was still being developed as part of the Klein project, which...
tried to break down the dichotomy between the classful programming world and the objectful execution world. While this helped programmers focus on run-time objects, it sacrificed code-level knowledge about the relationships between them. DCI restores this knowledge in Contexts and in the static relationships between role methods. - Dependency injectionDependency injectionDependency injection is a design pattern in object-oriented computer programming whose purpose is to improve testability of, and simplify deployment of components in very large software systems....
is a longstanding approach to change the functionality of an object at run time by allowing it to "outsource" some of its execution to an external object that can be re-bound at will. Most implementations of dependency injection lead to the self schizophreniaSchizophrenia (object-oriented programming)Object schizophrenia or self schizophrenia is a complication arising from delegation and related techniques in object-oriented programming.An object can be defined as a computing concept combining data and behavior, and having an identity. Objects are typically built on class systems...
problem, which implementations of DCI address properly. Systems such as Elmo use this approach, which brings additional complexity to resolve method ambiguity and duplicate data member names. - Multi-paradigm design attempted to separate behavior and structure by according the behavior to a procedural design and the structural component to objects, allowing free access between them, in accordance with the design principles of C++. However, multi-paradigm design does a poor job of expressing the relationship between the procedural and structural parts of design, and in general cannot realize the cohesiveness of the DCI approach.
- Aspect-oriented programmingAspect-oriented programmingIn computing, aspect-oriented programming is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns...
(AOP) is perhaps the closest historic relative to DCI. However, most use of Aspects is closely tied to the programmer perspective rather than to the end user mental model of use cases. Further, without strong tool support, Aspects usually make code less readable from the perspective of understanding what actually goes on at a given pointcutPointcutIn aspect-oriented computer programming, a pointcut is a set of join points. Whenever the program execution reaches one of the join points described in the pointcut, a piece of code associated with the pointcut is executed. This allows a programmer to describe where and when additional code...
. The main difference is that in DCI, the structure of the algorithm is primary, and its interaction with code outside of itself is viewed as secondary and minimal. Furthermore, such interaction honors the encapsulation of the code with which it interacts. In AOP, the pointcutPointcutIn aspect-oriented computer programming, a pointcut is a set of join points. Whenever the program execution reaches one of the join points described in the pointcut, a piece of code associated with the pointcut is executed. This allows a programmer to describe where and when additional code...
and adviceAdvice in aspect-oriented programmingIn aspect and functional programming, advice describes a class of functions which modify other functions when the latter are run; it is a certain function, method or procedure that is to be applied at a given join point of a program....
carry equal importance and though physically disjoint, must be understood together to understand the code, because the advice is invasive at the pointcutPointcutIn aspect-oriented computer programming, a pointcut is a set of join points. Whenever the program execution reaches one of the join points described in the pointcut, a piece of code associated with the pointcut is executed. This allows a programmer to describe where and when additional code...
. While AOP provides an administrative grouping of a related collection of individual local modifications that together cross-cut the primary structure of the code, DCI is a semantic expression of an algorithm with first-class analysis standing that invokes existing object methods. Think of DCI as a way of taking a large adviceAdvice in aspect-oriented programmingIn aspect and functional programming, advice describes a class of functions which modify other functions when the latter are run; it is a certain function, method or procedure that is to be applied at a given join point of a program....
and allowing parts of it to be injected into a number of regularized pointcutPointcutIn aspect-oriented computer programming, a pointcut is a set of join points. Whenever the program execution reaches one of the join points described in the pointcut, a piece of code associated with the pointcut is executed. This allows a programmer to describe where and when additional code...
s.