Aspect-oriented programming: Difference between revisions

Revision as of 20:46, 23 May 2021

Revision as of 18:57, 20 June 2021

Line 16:

AOP has several direct antecedents A1 and A2:<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 | url-status = live | archive-url = https://web.archive.org/web/20160112141810/http://www.cs.ubc.ca/%7Egregor/papers/kiczales-ECOOP1997-AOP.pdf | archive-date = 2016-01-12 }}</ref> [[reflection (computer programming)|reflection]] and [[Metaobject|metaobject protocol]]s, [[subject-oriented programming]], Composition Filters and Adaptive Programming.<ref>"Adaptive Object Oriented Programming: The Demeter Approach with Propagation Patterns" ''Karl Liebherr'' 1996 {{ISBN|0-534-94602-X}} presents a well-worked version of essentially the same thing (Lieberherr subsequently recognized this and reframed his approach).</ref>

[[Gregor Kiczales]] and colleagues at [[Xerox PARC]] developed the explicit concept of AOP, and followed this with the [[AspectJ]] AOP extension to Java. IBM's research team pursued a tool approach over a language design approach and in 2001 proposed [[Hyper/J]] and the [[Concern Manipulation Environment]], which have not seen wide usage.

The examples in this article use AspectJ.

Line 176:

Standard terminology used in Aspect-oriented programming may include:

;Cross-cutting concerns: {{main article|Cross-cutting concern}} Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Further concerns can be related to security such as [[Access control#Computer security|access control]] <ref name="dewin2002">B. De Win, B. Vanhaute and B. De Decker. "Security through aspect-oriented programming". In ''Advances in Network and Distributed Systems Security'' (2002).</ref> or [[Information flow (information theory)|information flow control]].<ref name="pasquier2014">T. Pasquier, J. Bacon and B. Shand. "FlowR: Aspect Oriented Programming for Information Flow Control in Ruby". In ''ACM Proceedings of the 13th international conference on Modularity (Aspect Oriented Software Development)'' (2014).</ref> Even though each class has a very different primary functionality, the code needed to perform the secondary functionality is often identical.

;Advice: {{main article|Advice (programming)}} This is the additional code that you want to apply to your existing model. In our example, this is the logging code that we want to apply whenever the thread enters or exits a method.

;Pointcut: {{main article|Pointcut}} This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied. In our example, a pointcut is reached when the thread enters a method, and another pointcut is reached when the thread exits the method.

Line 184:

Aspects emerged from [[object-oriented programming]] and [[computational reflection]]. AOP languages have functionality similar to, but more restricted than [[Metaobject|metaobject protocols]]. Aspects relate closely to programming concepts like [[subjects (programming)|subjects]], [[mixin]]s, and [[delegation (programming)|delegation]]. Other ways to use aspect-oriented programming paradigms include [[Composition Filters]] and the [[Hyper/J|hyperslices]] approach. Since at least the 1970s, developers have been using forms of interception and dispatch-patching that resemble some of the implementation methods for AOP, but these never had the semantics that the crosscutting specifications provide written in one place. {{Citation needed|date=February 2019}}

Designers have considered alternative ways to achieve separation of code, such as [[C Sharp (programming language)|C#]]'s partial types, but such approaches lack a quantification mechanism that allows reaching several join points of the code with one declarative statement.{{factcitation needed|date=May 2021}}

Though it may seem unrelated, in testing, the use of mocks or stubs requires the use of AOP techniques, like around advice, and so forth. Here the collaborating objects are for the purpose of the test, a cross cutting concern. Thus the various Mock Object frameworks provide these features. For example, a process invokes a service to get a balance amount. In the test of the process, where the amount comes from is unimportant, only that the process uses the balance according to the requirements.{{factcitation needed|date=May 2021}}

== Adoption issues ==

Line 193:

Even with proper education, understanding crosscutting concerns can be difficult without proper support for visualizing both static structure and the dynamic flow of a program.<ref name="harmful" /> Beginning in 2002, AspectJ began to provide IDE plug-ins to support the visualizing of crosscutting concerns. Those features, as well as aspect code assist and [[Code refactoring|refactoring]] are now common.

Given the power of AOP, if a programmer makes a logical mistake in expressing crosscutting, it can lead to widespread program failure. Conversely, another programmer may change the join points in a program &ndash; e.g., by renaming or moving methods &ndash; in ways that the aspect writer did not anticipate, with [[unforeseen consequences]]. One advantage of modularizing crosscutting concerns is enabling one programmer to affect the entire system easily; as a result, such problems present as a conflict over responsibility between two or more developers for a given failure. However, the solution for these problems can be much easier in the presence of AOP, since only the aspect needs to be changed, whereas the corresponding problems without AOP can be much more spread out.{{factcitation needed|date=May 2021}}

==Criticism==