Subject-oriented programming: Difference between revisions

Revision as of 16:35, 13 October 2023

Latest revision as of 03:36, 11 August 2025

(5 intermediate revisions by 4 users not shown)

Line 1:

In [[computing]], '''subject-oriented programming''' is an [[Object-oriented programming|object-oriented]] [[programming paradigm|software paradigm]] in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions ("subjects") of the objects. The term and concepts were first published in September 1993 in a conference paper<ref>William Harrison and Harold Ossher, Subject-Oriented Programming - A Critique of Pure Objects, Proceedings of 1993 Conference on Object-Oriented Programming Systems, Languages, and Applications, September 1993</ref> which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996.<ref>{{Cite web|url=httphttps://www.sigplan.org/Awards/OOPSLA/|title=Most Influential OOPSLA Paper Award|website=www.sigplan.org}}</ref> As illustrated in that paper, an analogy is made with the contrast between the philosophical views of [[Plato]] and [[Immanuel Kant|Kant]] with respect to the characteristics of "real" objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird's nor the tax-assessor's additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant's analysis, the same may be true even of characteristics we think of as intrinsic.

{{Cleanup bare URLs|date=August 2022}}

{{Programming paradigms}}

In [[computing]], '''subject-oriented programming''' is an [[Object-oriented programming|object-oriented]] [[programming paradigm|software paradigm]] in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions ("subjects") of the objects. The term and concepts were first published in September 1993 in a conference paper<ref>William Harrison and Harold Ossher, Subject-Oriented Programming - A Critique of Pure Objects, Proceedings of 1993 Conference on Object-Oriented Programming Systems, Languages, and Applications, September 1993</ref> which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996.<ref>{{Cite web|url=http://www.sigplan.org/Awards/OOPSLA|title=Most Influential OOPSLA Paper Award}}</ref> As illustrated in that paper, an analogy is made with the contrast between the philosophical views of [[Plato]] and [[Immanuel Kant|Kant]] with respect to the characteristics of "real" objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird's nor the tax-assessor's additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant's analysis, the same may be true even of characteristics we think of as intrinsic.

Subject-oriented programming advocates the organization of the [[Class (computer science)|classes]] that describe [[Object (computer science)|objects]] into "subjects", which may be composed to form larger subjects. At points of access to fields or [[Method (computer science)|methods]], several subjects' contributions may be composed. These points were characterized as the [[join-point]]s<ref>Harold Ossher , Peri Tarr. Operation-Level Composition: A Case in (Join) Point, in ECOOP '98 Workshop Reader, 406–409</ref> of the subjects. For example, if a tree is cut down, the methods involved may need to join behavior in the bird and tax-assessor's subjects with that of the tree's own. It is therefore fundamentally a view of the compositional nature of software development, as opposed to the algorithmic (procedural) or representation-hiding (object) nature.

==Relationships==

Line 12 ⟶ 10:

* the aspect transparently forces the cross-cutting behavior on object classes and other software entities

In the subject-oriented view, the cross-cut may be placed separately from the aspect (subject) and the behavior is not forced by the aspect, but governed by rules of composition. Hindsight<ref>William Harrison. De-constructing and Re-constructing Aspect-Orientation, Seventh Annual Workshop on Foundations of Aspect Languages, Brussels, Belgium, 1 April 2008, edited by Gary T. Leavens , ACM Digital Library, 2008, pp. 43-50</ref> makes it also possible to distinguish aspect-oriented programming by its introduction and exploitation of the concept of a query-like [[pointcut]] to externally impose the join-points used by aspects in general ways.

In the presentation of subject-oriented programming, the join-points were deliberately restricted to field access and method call on the grounds that those were the points at which well-designed frameworks were designed to admit functional extension. The use of externally imposed pointcuts is an important linguistic capability, but remains one of the most controversial features of aspect-oriented programming.<ref>Friedrich Steimann. The paradoxical success of aspect-oriented programming, Proceedings of the 21st annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, Portland, Oregon, USA , 2006, pp. 481 - 497</ref>

===Relationship to aspect-oriented software development===

By the turn of the millennium, it was clear that a number of research groups were pursuing different technologies that employed the composition or attachment of separately packaged state and function to form objects.<ref>Communications of the ACM, Vol. 44, No. 10, October 1994, pp. 28-95</ref> To distinguish the common field of interest from Aspect-Oriented Programming with its particular patent definitions and to emphasize that the compositional technology deals with more than just the coding phase of software development, these technologies were organized together under the term [[Aspect-Oriented Software Development]],<ref>http{{Cite web|url=https://aosd.net/|title=Home|website=AOSD.net}}</ref> and an organization and series on international conferences begun on the subject. Like aspect-oriented programming, subject-oriented programming, composition filters, [[feature-oriented programming]] and adaptive methods are considered to be aspect-oriented software development approaches.

==Dimensions==

Line 37 ⟶ 35:

* and a priority ordering specification to resolve conflicts among conflicting rules.

Both Hyper/J and CME are available, from alphaWorks<ref>{{Cite web|url=http://www.alphaworks.ibm.com/tech/hyperj|title = Legacy Communities - IBM Community| date=23 April 2009 }}</ref> or sourceforge,<ref>{{Cite web|url=httphttps://sourceforge.net/projects/cme/|title=Concern Manipulation Environment (CME)|date=24 April 2015 }}</ref> respectively, but neither is actively supported.

===Subject-oriented programming as a "third dimension"===

Method dispatch in object oriented programming can be thought of as "two dimensional" in the sense that the code executed depends on both the method name and the object in question. This can be contrasted<ref>[{{Cite web|url=http://www.jot.fm/issues/issue_2008_03/article4/ |title=Journal of Object Technology: Context Oriented Programming]}}</ref> with procedural programming, where a procedure name resolves directly, or one dimensionally, onto a subroutine, and also to subject oriented programming, where the sender or subject is also relevant to dispatch, constituting a third dimension.

==See also==

Line 54 ⟶ 52:

* [http://www.eclipse.org/technology/archived.php Eclipse Archived Technology Projects]

* [http://amethyst.io Amethyst: a JavaScript library for Subject-Oriented Programming]

{{Programming paradigms navbox}}

[[Category:Object-oriented programming]]