Content deleted Content added
m Reverted 1 edit by 111.119.187.42 (talk) to last revision by 86.9.128.236 (TW) |
Minilexikon (talk | contribs) m Structured by grouping headings |
||
Line 4:
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==
===Relationship to aspect-oriented programming===
The introduction of [[aspect-oriented programming]] in 1997<ref>{{Cite conference | doi = 10.1007/BFb0053381| title = Aspect-oriented programming| work = Proceedings of the 11th European Conference on Object-Oriented Programming| conference = [[European Conference on Object-Oriented Programming|ECOOP]]'97| volume = 1241| pages = 220–242| series = [[Lecture Notes in Computer Science|LNCS]]| year = 1997| last1 = Kiczales | first1 = G. | author1-link = Gregor Kiczales | last2 = Lamping | first2 = J. | last3 = Mendhekar | first3 = A. | last4 = Maeda | first4 = C. | last5 = Lopes | first5 = C. | last6 = Loingtier | first6 = J. M. | last7 = Irwin | first7 = J. | isbn = 3-540-63089-9| citeseerx = 10.1.1.115.8660| url = http://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf}}</ref> raised questions about its relationship to subject-oriented programming, and about the difference between subjects and aspects. These questions were unanswered for some time, but were addressed in the patent on Aspect-oriented programming filed in 1999<ref>Kiczales; Gregor J.; Lamping; John O.; Lopes; Cristina V.; Hugunin; James J.; Hilsdale; Erik A.; Boyapati; Chandrasekhar, Aspect Oriented Programming, United States Patent 6,467,086, October 15, 2002</ref> in which two points emerge as characteristic differences from earlier art:
Line 14 ⟶ 15:
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://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|feature oriented programming]] and adaptive methods are considered to be aspect-oriented software development approaches.
==Dimensions==
===Multi-dimensional separation of concerns, Hyper/J, and the Concern Manipulation Environment===
The original formulation of subject-oriented programming deliberately envisioned it as a packaging technology – allowing the space of functions and data types to be extended in either dimension. The first implementations had been for C++,<ref>Harold Ossher, Matthew Kaplan, William Harrison, Alexander Katz and Vincent Kruskal, Subject-Oriented Composition Rules, Proceedings of 1995 Conference on Object-Oriented Programming Systems, Languages, and Applications, October 1995</ref> and Smalltalk.<ref>Hafedh Mili, William Harrison, Harold Ossher, Supporting Subject-Oriented Programming in Smalltalk, Proceedings of TOOLS USA 96, August 1996</ref> These implementations exploited the concepts of software labels and composition rules to describe the joining of subjects.
Line 36 ⟶ 38:
Both Hyper/J and CME are available, from alphaWorks<ref>http://www.alphaworks.ibm.com/tech/hyperj</ref> or sourceforge,<ref>http://sourceforge.net/projects/cme/</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>[http://www.jot.fm/issues/issue_2008_03/article4/ 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.
| |||