Data, context and interaction: Difference between revisions

Revision as of 11:35, 24 September 2022

Revision as of 11:45, 24 September 2022

Line 72:

==History==

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]].{{citation<ref needed|datename=February"Artima" 2016}}/><ref name="DCI Paradigm" /><ref name="Working with objects" />.

DCI arose largely as an outgrowth of Trygve Reenskaug's work on role-based modeling.<ref>Trygve Reenskaug. Working with Objects: The OOram Software Engineering Method. Prentice-Hall, 1995.</ref> Trygve had long recognized that Roles played a central part in the way programmers 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]].{{citation needed|date=February 2016}}

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 (computer science)|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. JimJames 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 adaptating these ideas to [[Ruby (programming language)|Ruby]] and [[Java (programming language)|Java]] over the next year or so with the Qi4j framework.<ref name="Qi4j" />. Many additional language adaptations followed a session at the JaOO conference in Denmark in September 2008. In 2010 the language Marvin was created by Rune Lund-Søltoft. It was the first language build with native support for DCI. Marvin was mainly meant as a proof of concept to showcase the idea of "injection lessinjectionless DCI". Most of the previous implementations altered the role player objects in a way that would be visible outside of the context. James Coplien created the language trygve based on the same idea, the first language build from the ground up to support DCI.

Different approaches taken for the evolution of object-oriented programming, both on a language and [[programming pattern|pattern]] level, agree to various degrees with DCI:

* [[Mixin]]s are a way of encapsulating code for specific what-the-system-does functionality in closed form; however, there is no consistent mechanism to link multiple mixins into a unit at the level of a [[use case]]. They can be employed to implement to the concept of Role in DCI, although not in a strict sense.{{citation needed|date=February 2016}}

* [[Multiple dispatch]] was an early attempt to more fully separate an algorithm from the objects that were involved in its execution, which can be complemented with 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.{{citation needed|date=February 2016}}

* True object-oriented programming languages like [[Self (programming language)|Self]] attempt to break down the dichotomy between the domains of classful programming and objectful execution, which helps programmers focus on run-time objects. DCI restores the code-level knowledge about the relationships between them in Contexts and in the static relationships between Role methods.{{citation<ref needed|datename=February"Artima" 2016}}/>.

* [[Dependency injection]] 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{{which|date=October 2014}} of dependency injection lead to the [[Schizophrenia (object-oriented programming)|self schizophrenia]] problem,<ref>{{citationcite web needed|datelast1=OctoberCoplien 2014|first1=James |title=Why isn't it DCI if you use a wrapper object to represent the Role? |url=https://fulloo.info/doku.php?id=why_isn_t_it_dci_if_you_use_a_wrapper_object_to_represent_the_role |publisher=DCI FAQ}}</ref>, 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.<ref>James Leigh, Elmo User Guide, http://www.openrdf.org/doc/elmo/1.5/user-guide.html {{Webarchive|url=https://web.archive.org/web/20110721134455/http://www.openrdf.org/doc/elmo/1.5/user-guide.html |date=2011-07-21 }}</ref>{{Full citation needed|date=October 2014}}

* Multi-paradigm design<ref>James Coplien, Multi-paradigm design for C++. Addison-Wesley, 1998.</ref> attempts 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 accord with the design principles of C++. The DCI approach can improve on expressing the relationship between the procedural and structural parts of design and general cohesiveness.<ref name="Empirical Study on Code Comprehension">{{citationcite web |last1=Valdecantos |first1=Héctor Adrián |last2=Tarrit |first2=Katy |last3=Mirakhorli |first3=Mehdi |last4=Coplien |first4=James O. |title=An Empirical Study on Code Comprehension: Data Context Interaction Compared to Classical Object Oriented |url=https://www.researchgate.net/publication/345728720_An_Empirical_Study_on_Code_Comprehension_Data_Context_Interaction_Compared_to_Classical_Object_Oriented |website=2017 IEEE/ACM 25th International Conference on Program Comprehension (ICPC) |pages=275–285 |doi=http://dx.doi.org/10.1109/ICPC.2017.23 needed|date=AugustMay 20122017}}</ref>.

The challenges of object-oriented programming can also be met by addressing its issues on the paradigm level.