Data, context and interaction: Difference between revisions

Revision as of 09:00, 13 April 2021

Revision as of 09:01, 13 April 2021

Line 93:

* [[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> As such, DCI sacrifices the advantages of inheritance for the complete avoidance of its shortcomings, while in Role Oriented Programming takes a mitigation approach, awarding importance to the balancing of the dangers with its popular advantages.

==References==