Data, context and interaction: Difference between revisions

Content deleted Content added
History: split AOP, ROP presentation from the big grouping
History: NPOV: Use a presentation based on complementarity rather than superiority. (to be cont.)
Line 90:
The challenges of object-oriented programming can also be met by addressing its issues on the paradigm level.
 
rather than to the end user mental model of [[use cases]].
* [[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}}
 
* [[Aspect-oriented programming]] (AOP) is perhaps the closest historic relative to DCI. However, mostMost use of Aspects is closely tied to the programmer perspective rather than to the end user mental model of [[use cases]]. Further,and withoutrequire strong tool support, Aspectsto usuallyprovide makegood codeunderstanding less readable fromof the perspectivesoftware's of understanding what actually goesbehavivour on at aany given [[pointcut]]. The main difference is that in DCI, the structure of the algorithm is primary, and its interaction with codea outsidestrong ofemphasis itselfon isits viewedisolation asfrom secondarycode andoutside minimal. Furthermoreitself, such interaction honors the encapsulation of theimproving code with which it interactsreadability. 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.