Content deleted Content added
→History: NPOV: Use a presentation based on complementarity rather than superiority. (to be cont.) |
m →History: ce |
||
Line 84:
* [[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.{{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
* [[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}}
| |||