Data, context and interaction: Difference between revisions

Revision as of 08:15, 13 April 2021

Revision as of 08:25, 13 April 2021

Line 82:

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 wereare 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]]. MixinsThey arecan verybe employed to closeimplement to the concept of Role in DCI.{{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, butwhich itcan lackedbe 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]] triedattempt to break down the dichotomy between the domains of classful programming and objectful execution. While, thiswhich helpedhelps programmers focus on run-time objects,. itDCI sacrificedrestores the code-level knowledge about the relationships between them. DCIto restoresbe this knowledgepreserved in Contexts and in the static relationships between Role methods.{{citation needed|date=February 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,{{citation needed|date=October 2014}} 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> 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 accord 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.{{citation needed|date=August 2012}}