Content deleted Content added
m Dating maintenance tags: {{Brokenlink}} |
m punctuation |
||
Line 1:
{{Cleanup|reason=I added the empty Examples section to the top when I don't really know where it properly belongs. I wish I could have just used <nowiki>{{Expand|reason=needs examples|date=March 2012}}</nowiki> instead, but the template has been semi-deleted.|date=March 2012}}
{{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 [[Subject (programming)|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>{{brokenlink|date=May 2013}}http://www.sigplan.org/award-oopsla.htm</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
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.
|