Data, context and interaction: Difference between revisions

Revision as of 10:08, 14 October 2018

Revision as of 13:02, 17 July 2019

Line 71:

Implementation techniques differ across programming languages. What is common to many approaches is that Roles are represented by such constructs as generics, templates, classes, or [[Traits (computer science)|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 [[Role-oriented programming|Roles]], [[method injection]] is usually needed. [[Traits (computer science)|Traits]]<ref>Nathaniel Schärli et al. Traits: Composable units of behavior. http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf</ref> are one common programming language technique to support [[method injection]]. Some languages, such as [[Scala (programming language)|Scala]], have native support for [[Traits (computer science)|traits]], while other languages (e.g., [[Ruby (programming language)|Ruby]] and [[Python (programming language)|Python]]) allow run time injection of methods. In [[Java (programming language)|Java]], pre-compiler tricks based on annotations are needed to support DCI.

Several example implementations exist: [[Smalltalk]]-[[Squeak]],<ref>The Common Sense of Object Oriented Programming by Trygve Reenskaug, http://heim.ifi.uio.no/~trygver/2009/commonsense.pdf</ref> [[C++]],<ref>Full OO DCI Documentation C++ Examples, http://fulloo.info/Examples/C++Examples/index.html</ref> [[C Sharp (programming language)|C#]],<ref>C# source code on Object-Composition Google group,http://object-composition.googlegroups.com/web/20090504_C%23_DCI.zip?gda=KuAYkEcAAADrRvU1tICZInrYQGkdqcjVB9LJpDFQtNZStXvSrZaE07Ryyh4ndddBwXohD2r2F8gbzHe87USdioT9uNiA7PHaeV4duv6pDMGhhhZdjQlNAw{{Dead link|date=July 2019 |bot=InternetArchiveBot |fix-attempted=yes }} 17.10.2009</ref> [[Ruby (programming language)|Ruby]],<ref>Ruby source code on Object-Composition Google group,https://groups.google.com/group/object-composition/browse_thread/thread/561f638b43f1b960# 17.10.2009</ref> [[JavaScript]],<ref>JavaScript source code on Object-Composition Google group,https://groups.google.com/group/object-composition/browse_thread/thread/8ec4cf18e127cc3e# 17.10.2009</ref> [[Python (programming language)|Python]],<ref>https://pypi.python.org/pypi/roles</ref> Qi4J ([[Java (programming language)|Java]]),<ref>Qi4j source code on Object-Composition Google group,https://groups.google.com/group/object-composition/browse_thread/thread/fe317e615b9008fe# 17.10.2009</ref> [[Scala (programming language)|Scala]], [[Perl]],<ref>Release on CPAN: https://metacpan.org/release/DCI {{Webarchive|url=https://web.archive.org/web/20120124054743/https://metacpan.org/release/DCI |date=2012-01-24 }}</ref> and [[PHP]].<ref>PHP source code on Google, https://code.google.com/p/php-coredci</ref> and [http://fulloo.info/Examples/ several] have been added to the fulloo.info site maintained by the creators of DCI.

==History==

Line 85:

* [[Multiple dispatch]] 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.{{citation needed|date=February 2016}}

* True object-oriented programming languages like [[Self (programming language)|Self]] tried to break down the dichotomy between the domains of classful programming and objectful execution. 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.{{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}}

* [[Aspect-oriented programming]] (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 [[pointcut]]. 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 [[pointcut]] and [[Advice in aspect-oriented programming|advice]] carry equal importance and though physically disjoint, must be understood together to understand the code, because the advice is invasive at the [[pointcut]]. 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. DCI cann be thought of as a way of taking a large [[Advice in aspect-oriented programming|advice]] and allowing parts of it to be injected into a number of regularized [[pointcut]]s.{{citation needed|date=February 2016}}

* [[Role-oriented programming]] brings together ideas from [[Aspect-oriented programming]], conceptual modeling <ref>Friedrich Steimann, On the representation of roles in object-oriented and conceptual modelling, 2000, http://www.fernuni-hagen.de/ps/veroeffentlichungen/zeitschrift_46129.shtml</ref> and more. Early attempts (1991) defined roles in an independent fashion,<ref>Joel Richardson and Peter Schwarz, Aspects: extending objects to support multiple, independent roles, 1991, http://www.informatik.uni-trier.de/~ley/db/conf/sigmod/RichardsonS91.html {{Webarchive|url=https://web.archive.org/web/20071017185308/http://www.informatik.uni-trier.de/~ley/db/conf/sigmod/RichardsonS91.html |date=2007-10-17 }}</ref> but more recent approaches (2002 and onward) converge in emphasizing that roles depend on context (also "teams" <ref>Stephan Herrmann, Object Teams: Improving Modularity for Crosscutting Collaborations, http://www.objectteams.org/publications/index.html#NODe02, 2002</ref> or "institutions" <ref>Guido Baldoni et al., Roles as a coordination construct: introducing powerJava, 2005, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.77.6337</ref>). In role-oriented programming, roles are defined with respect to some intrinsic (or base) entity, which corresponds to the data-role dichotomy in DCI. The concept of context is essentially the same in both approaches. Both approaches emphasize the interaction among a group of roles.

:Several differences can be identified. Role-oriented programming is focused on adding support for roles to object-oriented ''programming languages'' where emphasis is on increasing the expressiveness of a programming language and enabling more designs. In comparison, DCI has stronger focus on the ''method'' of how mental models should be captured, defining this method in part as restrictions on what should be regarded a legal design corresponding to DCI. For example: Authors of DCI tend to discourage some use of inheritance (e.g. "within DCI you do not inherit roles" <ref>J. Coplien, posted in Object-Composition Google group, https://groups.google.com/forum/?hl=en#!topic/object-composition/haza-J2Doz8 21.10.2010</ref>) whereas role-oriented programming embraces (and even enhances) inheritance as a central concept of object-orientated programming, supporting free combination with other concepts. DCI emphasises that [[Schizophrenia (object-oriented programming)|self schizophrenia]] should be avoided, whereas role-oriented programming claimed to manage split objects in such a way that schizophrenia was no longer a problem <ref>Stephan Herrmann, Demystifying Object Schizophrenia, 2010, http://www.objectteams.org/publications/index.html#MASPEGHI10</ref> but a facilitator for more flexible designs. A later paper by the DCI authors claims that self-schizophrenia remains a problem in role-oriented programming using a counter-example based on a modified implementation of [[Dijkstra's algorithm]].<ref>James O. Coplien, and Trygve Mikkjel Heyerdahl Reenskaug, The data, context and interaction paradigm. In Gary T. Leavens (Ed.): Conference on Systems, Programming, and Applications: Software for Humanity, SPLASH '12, Tucson, AZ, USA, October 21–25, 2012. ACM 2012, {{ISBN|978-1-4503-1563-0}}, pp. 227 - 228, http://dl.acm.org/citation.cfm?id=2384782&dl=ACM&coll=DL.</ref>