Aspect-oriented programming: Difference between revisions

Revision as of 12:47, 12 March 2024

Revision as of 17:29, 4 April 2024

Line 6:

AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while '''aspect-oriented software development''' refers to a whole engineering discipline.

Aspect-oriented programming entails breaking down program logic into distinctcohesive partsareas of functionality (so-called ''concerns'', cohesive areas of functionality). Nearly all programming paradigms support some level of grouping and [[encapsulation (computer science)|encapsulation]] of concerns into separate, independent entities by providing abstractions (e.g., functions, procedures, modules, classes, methods) that can be used for implementing, abstracting, and composing these concerns. Some concerns "cut across" multiple abstractions in a program, and defy these forms of implementation. These concerns are called ''cross-cutting concerns'' or horizontal concerns.

[[Logging (computing)|Logging]] exemplifies a crosscuttingcross-cutting concern because a logging strategy must affect every logged part of the system. Logging thereby ''crosscuts'' all logged classes and methods.

All AOP implementations have some crosscuttingcross-cutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided. For example, interceptors that specify the methods to express a limited form of crosscuttingcross-cutting, without much support for type-safety or debugging. [[AspectJ]] has a number of such expressions and encapsulates them in a special class, called an [[aspect (computer science)|aspect]]. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying [[Advice in aspect-oriented programming|advice]] (additional behavior) at various [[join point]]s (points in a program) specified in a quantification or query called a [[pointcut]] (that detects whether a given join point matches). An aspect can also make binary-compatible structural changes to other classes, such as adding members or parents.

==History==

Line 22:

== Motivation and basic concepts ==

Typically, an aspect is ''scattered'' or ''tangled'' as code, making it harder to understand and maintain. It is scattered by the function (such as logging) being spread over a number of unrelated functions that might use ''its'' function, possibly in entirely unrelated systems or written in different source languages. Thus, changing logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. Changing one concern thus entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

For example, consider a banking application with a conceptually very simple method for transferring an amount from one account to another:<ref>Note: The examples in this article appear in a syntax that resembles that of the [[Java (programming language)|Java]] language.</ref>

Line 37:

However, this transfer method overlooks certain considerations that a deployed application would require, such as verifying that the current user is authorized to perform this operation, encapsulating [[database transaction|database transactions]] to prevent accidental data loss, and logging the operation for diagnostic purposes.

A version with all those new concerns couldmight look somewhat like this:

<syntaxhighlight lang="java">

Line 65:

In this example, other interests have become ''tangled'' with the basic functionality (sometimes called the ''business logic concern''). Transactions, security, and logging all exemplify ''[[cross-cutting concern]]s''.

Now consider what would happen if we suddenly need to change the security considerations for the application. In the program's current version, security-related operations appear ''scattered'' across numerous methods, and such a change would require a major effort.

AOP attemptstries to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called ''aspects''. Aspects can contain ''advice'' (code joined to specified points in the program) and ''inter-type declarations'' (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account. The [[pointcut]] defines the times ([[join point]]s) when one can access a bank account, and the code in the advice body defines how the security check is implemented. That way, both the check and the places can be maintained in one place. Further, a good pointcut can anticipate later program changes, so if another developer creates a new method to access the bank account, the advice will apply to the new method when it executes.

So for the example above implementing logging in an aspect:

Line 102:

| Pointcuts are specified by combinations of ''primitive pointcut designators'' (PCDs).

"Kinded" PCDs match a particular kind of join point (e.g., method execution) and tend tooften take as input a Java-like signature as input. One such pointcut looks like this:

execution(* set*(*))

Line 143:

===Inter-type declarations===

''Inter-type declarations'' provide a way to express crosscuttingcross-cutting concerns affecting the structure of modules. Also known as ''open classes'' and ''[[extension method]]s'', this enables programmers to declare in one place members or parents of another class, typically to combine all the code related to a concern in one aspect. For example, if a programmer implemented the crosscuttingcross-cutting display-update concern using visitors, an inter-type declaration using the [[visitor pattern]] might look like this in AspectJ:

<syntaxhighlight lang="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 OOobject-oriented 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.

;PointcutAdvice: {{main article|PointcutAdvice (programming)}} This is the termadditional givencode tothat theyou pointwant ofto executionapply into the application at which cross-cutting concern needs toyour beexisting appliedmodel. In our example, a pointcutthis is reached when the threadlogging enterscode athat method,we andwant anotherto pointcutapply is reached whenwhenever the thread enters or exits thea method.:

;Pointcut: {{main article|Pointcut}} This refers 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.

;

;Aspect: {{main article|Aspect (computer science)}} The combination of the pointcut and the advice is termed an aspect. In the example above, we add a logging aspect to our application by defining a pointcut and giving the correct advice.

== Comparison to other programming paradigms ==

Aspects emerged from [[object-oriented programming]] and [[reflective programming]]. 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 crosscuttingcross-cutting 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.{{citation needed|date=May 2021}}

Though it may seem unrelated, in testing, the use of mocks or stubs requires the use of AOP techniques, such as around advice. 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, it is unimportant where the amount comes from, but only that the process uses the balance according to the requirements.{{citation needed|date=May 2021}}

== Adoption issues ==

Programmers need to be able to read and understand code to prevent errors.<ref>[[Edsger Dijkstra]], [http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF ''Notes on Structured Programming''] {{webarchive|url=https://web.archive.org/web/20061012020239/http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF |date=2006-10-12}}, pg. 1-2</ref>

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

Given the power of AOP, making a logical mistake in expressing crosscuttingcross-cutting can lead to widespread program failure. Conversely, another programmer may change the join points in a program, such as by renaming or moving methods, in ways that the aspect writer did not anticipate and with [[unforeseen consequences]]. One advantage of modularizing crosscuttingcross-cutting concerns is enabling one programmer to easily affect the entire system. As a result, such problems manifest as a conflict over responsibility between two or more developers for a given failure. AOP can expedite solving these problems, as only the aspect must be changed. Without AOP, the corresponding problems can be much more spread out.{{citation needed|date=May 2021}}

==Criticism==

Line 221 ⟶ 223:

General criticisms are that AOP purports to improve "both modularity and the structure of code", but some counter that it instead undermines these goals and impedes "independent development and understandability of programs".<ref name="steimann">{{Cite journal |doi=10.1145/1167515.1167514 |title=The paradoxical success of aspect-oriented programming |journal=ACM SIGPLAN Notices |volume=41 |issue=10 |pages=481–497 |year=2006 |last1=Steimann |first1=F. |citeseerx=10.1.1.457.2210}}, ([http://people.dsv.su.se/~johano/ioor/succ_aop.pdf slides] {{webarchive|url=https://web.archive.org/web/20160304060007/http://people.dsv.su.se/~johano/ioor/succ_aop.pdf |date=2016-03-04}},[http://www.eecs.ucf.edu/~leavens/modular-aop/Discussion.pdf slides 2] {{webarchive|url=https://web.archive.org/web/20150923234021/http://www.eecs.ucf.edu/~leavens/modular-aop/Discussion.pdf |date=2015-09-23}}, [http://www.oopsla.org/2006/submission/essays/the_paradoxical_success_of_aspect-oriented_programming.html abstract] {{webarchive|url=https://web.archive.org/web/20150924060711/http://www.oopsla.org/2006/submission/essays/the_paradoxical_success_of_aspect-oriented_programming.html |date=2015-09-24}}), Friedrich Steimann, Gary T. Leavens, [[OOPSLA]] 2006</ref> Specifically, quantification by pointcuts breaks modularity: "one must, in general, have whole-program knowledge to reason about the dynamic execution of an aspect-oriented program."<ref>{{cite web|url=http://www.eecs.ucf.edu/~leavens/modular-aop/|title=More Modular Reasoning for Aspect-Oriented Programs|access-date=11 August 2015|url-status=live|archive-url=https://web.archive.org/web/20150812045258/http://www.eecs.ucf.edu/~leavens/modular-aop/|archive-date=12 August 2015}}</ref> Further, while its goals (modularizing cross-cutting concerns) are well understood, its actual definition is unclear and not clearly distinguished from other well-established techniques.<ref name="steimann"/> Cross-cutting concerns potentially cross-cut each other, requiring some resolution mechanism, such as ordering.<ref name="steimann"/> Indeed, aspects can apply to themselves, leading to problems such as the [[liar paradox]].<ref>{{cite web|url=http://www.fernuni-hagen.de/ps/pubs/FOAL2006.pdf|title=AOP and the Antinomy of the Liar|website=fernuni-hagen.de|access-date=5 May 2018|url-status=live|archive-url=https://web.archive.org/web/20170809201001/http://www.fernuni-hagen.de/ps/pubs/FOAL2006.pdf|archive-date=9 August 2017}}</ref>

Technical criticisms include that the quantification of pointcuts (defining where advices are executed) is "extremely sensitive to changes in the program", which is known as the ''fragile pointcut problem''.<ref name="steimann"/> The problems with pointcuts are deemed intractable;. ifIf one replaces the quantification of pointcuts with explicit annotations, one obtains [[attribute-oriented programming]] instead, which is simply an explicit subroutine call and suffers the identical problem of scattering, thatwhich AOP was designed to solve.<ref name="steimann"/>

==Implementations==