Incomputing,aspect-oriented programming (AOP) is aprogramming paradigm that aims to increasemodularity by allowing theseparation ofcross-cutting concerns. It does so by adding behavior to existing code (anadvice)without modifying the code, instead separately specifying which code is modified via a "pointcut" specification, such as "log all function calls when the function's name begins with 'set'". This allows behaviors that are not central to thebusiness logic (such as logging) to be added to a program without cluttering the code of core functions.
AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, whileaspect-oriented software development refers to a whole engineering discipline.
Aspect-oriented programming entails breaking down program logic into cohesive areas of functionality (so-calledconcerns). Nearly all programming paradigms support some level of grouping andencapsulation 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 calledcross-cutting concerns or horizontal concerns.
Logging exemplifies a cross-cutting concern because a logging strategy must affect every logged part of the system. Logging therebycrosscuts all logged classes and methods.
All AOP implementations have some cross-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 cross-cutting, without much support for type-safety or debugging.AspectJ has a number of such expressions and encapsulates them in a special class, called anaspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applyingadvice (additional behavior) at variousjoin points (points in a program) specified in a quantification or query called apointcut (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.
AOP has several direct antecedents:[1]reflection andmetaobject protocols,subject-oriented programming, Composition Filters, and Adaptive Programming.[2]
Gregor Kiczales and colleagues atXerox PARC developed the explicit concept of AOP and followed this with theAspectJ AOP extension to Java. IBM's research team pursued a tool approach over a language design approach and in 2001 proposedHyper/J and theConcern Manipulation Environment, which have not seen wide use.
The examples in this article use AspectJ.
TheMicrosoft Transaction Server is considered to be the first major application of AOP followed byEnterprise JavaBeans.[3][4]
Typically, an aspect isscattered ortangled 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 useits function, possibly in entirely unrelated systems or written in different 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. Such an example inJava looks like:
sealedclassBankingExceptionextendsExceptionpermitsInsufficientFundsException,UnauthorisedUserException{// ...}publicclassBank{publicvoidtransfer(AccountfromAcc,AccounttoAcc,intamount)throwsBankingException{if(fromAcc.getBalance()<amount){thrownewInsufficientFundsException();}fromAcc.withdraw(amount);toAcc.deposit(amount);}}
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, encapsulatingdatabase transactions to prevent accidental data loss, and logging the operation for diagnostic purposes.
A version with all those new concerns might look like this:
importjava.util.logging.*;sealedclassBankingExceptionextendsExceptionpermitsInsufficientFundsException,UnauthorisedUserException{// ...}publicclassBank{privatestaticfinalLoggerlogger;privatefinalDatabasedatabase;publicvoidtransfer(AccountfromAcc,AccounttoAcc,intamount,Useruser)throwsBankingException{logger.info("Transferring money...");if(!isUserAuthorised(user,fromAcc)){logger.log(Level.WARNING,"User has no permission.");thrownewUnauthorisedUserException();}if(fromAcc.getBalance()<amount){logger.log(Level.WARNING,"Insufficient funds.");thrownewInsufficientFundsException();}fromAcc.withdraw(amount);toAcc.deposit(amount);database.commitChanges();// Atomic operation.logger.log(Level.INFO,"Transaction successful.");}}
In this example, other interests have becometangled with the basic functionality (sometimes called thebusiness logic concern). Transactions, security, and logging all exemplifycross-cutting concerns.
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 appearscattered across numerous methods, and such a change would require major effort.
AOP tries to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules calledaspects. Aspects can containadvice (code joined to specified points in the program) andinter-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. Thepointcut defines the times (join points) 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:
aspectLogger{Loggerlogger;voidBank.transfer(AccountfromAcc,AccounttoAcc,intamount,Useruser){logger.info("Transferring money...");}voidBank.getMoneyBack(Useruser,inttransactionId){logger.info("User requested money back.");}// Other crosscutting code.}
One can think of AOP as a debugging tool or a user-level tool. Advice should be reserved for cases in which one cannot get the function changed (user level)[5] or do not want to change the function in production code (debugging).
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:
Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.
"Kinded" PCDs match a particular kind of join point (e.g., method execution) and often take a Java-like signature as input. One such pointcut looks like this:
execution(*set*(*))
This pointcut matches a method-execution join point, if the method name starts with "set" and there is exactly one argument of any type.
"Dynamic" PCDs check runtime types and bind variables. For example,
this(Point)
This pointcut matches when the currently executing object is an instance of classPoint. Note that the unqualified name of a class can be used via Java's normal type lookup.
"Scope" PCDs limit the lexical scope of the join point. For example:
within(com.company.*)
This pointcut matches any join point in any type in thecom.company package. The* is one form of the wildcards that can be used to match many things with one signature.
Pointcuts can be composed and named for reuse. For example:
pointcutset():execution(*set*(*))&&this(Point)&&within(com.company.*);
set" andthis is an instance of typePoint in thecom.company package. It can be referred to using the name "set()".after():set(){Display.update();}
set() pointcut matches the join point, run the codeDisplay.update() after the join point completes."There are other kinds of JPMs. All advice languages can be defined in terms of their JPM. For example, a hypothetical aspect language forUML may have the following JPM:
Inter-type declarations provide a way to express cross-cutting concerns affecting the structure of modules. Also known asopen classes andextension methods, 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 cross-cutting display-update concern using visitors, an inter-type declaration using thevisitor pattern might look like this in AspectJ:
aspectDisplayUpdate{voidPoint.acceptVisitor(Visitorv){v.visit(this);}// other crosscutting code...}
This code snippet adds theacceptVisitor method to thePoint class.
Any structural additions are required to be compatible with the original class, so that clients of the existing class continue to operate, unless the AOP implementation can expect to control all clients at all times.
AOP programs can affect other programs in two different ways, depending on the underlying languages and environments:
The difficulty of changing environments means most implementations produce compatible combination programs through a type ofprogram transformation known asweaving. Anaspect weaver reads the aspect-oriented code and generates appropriate object-oriented code with the aspects integrated. The same AOP language can be implemented through a variety of weaving methods, so the semantics of a language should never be understood in terms of the weaving implementation. Only the speed of an implementation and its ease of deployment are affected by the method of combination used.
Systems can implement source-level weaving using preprocessors (as C++ was implemented originally inCFront) that require access to program source files. However, Java's well-defined binary form enables bytecode weavers to work with any Java program in .class-file form. Bytecode weavers can be deployed during the build process or, if the weave model is per-class, during class loading.AspectJ started with source-level weaving in 2001, delivered a per-class bytecode weaver in 2002, and offered advanced load-time support after the integration ofAspectWerkz in 2005.
Any solution that combines programs at runtime must provide views that segregate them properly to maintain the programmer's segregated model. Java's bytecode support for multiple source files enables any debugger to step through a properly woven .class file in a source editor. However, some third-party decompilers cannot process woven code because they expect code produced by Javac rather than all supported bytecode forms (see also§ Criticism, below).
Deploy-time weaving offers another approach.[6] This basically implies post-processing, but rather than patching the generated code, this weaving approachsubclasses existing classes so that the modifications are introduced by method-overriding. The existing classes remain untouched, even at runtime, and all existing tools, such as debuggers and profilers, can be used during development. A similar approach has already proven itself in the implementation of manyJava EE application servers, such asIBM'sWebSphere.
Standard terminology used in Aspect-oriented programming may include:
Aspects emerged fromobject-oriented programming andreflective programming. AOP languages have functionality similar to, but more restricted than,metaobject protocols. Aspects relate closely to programming concepts likesubjects,mixins, anddelegation. Other ways to use aspect-oriented programming paradigms includeComposition Filters and thehyperslices 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 cross-cutting specifications provide in one place.[citation needed]
Designers have considered alternative ways to achieve separation of code, such asC#'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]
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]
Programmers need to be able to read and understand code to prevent errors.[9]Even with proper education, understanding cross-cutting concerns can be difficult without proper support for visualizing both static structure and the dynamic flow of a program.[10] Starting in 2002, AspectJ began to provide IDE plug-ins to support the visualizing of cross-cutting concerns. Those features, as well as aspect code assist andrefactoring, are now common.
Given the power of AOP, making a logical mistake in expressing cross-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 withunforeseen consequences. One advantage of modularizing cross-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]
The most basic criticism of the effect of AOP is that control flow is obscured, and that it is not only worse than the much-malignedGOTO statement, but is closely analogous to the jokeCOME FROM statement.[10] Theobliviousness of application, which is fundamental to many definitions of AOP (the code in question has no indication that an advice will be applied, which is specified instead in the pointcut), means that the advice is not visible, in contrast to an explicit method call.[10][11] For example, compare the COME FROM program:[10]
5INPUTX10PRINT'Result is :'15PRINTX20COMEFROM1025X=X*X30RETURN
with an AOP fragment with analogous semantics:
main(){inputxprint(result(x))}inputresult(intx){returnx}around(intx):call(result(int))&&args(x){inttemp=proceed(x)returntemp*temp}
Indeed, the pointcut may depend on runtime condition and thus not be statically deterministic. This can be mitigated but not solved by static analysis and IDE support showing which advicespotentially match.
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".[12] 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."[13] 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.[12] Cross-cutting concerns potentially cross-cut each other, requiring some resolution mechanism, such as ordering.[12] Indeed, aspects can apply to themselves, leading to problems such as theliar paradox.[14]
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 thefragile pointcut problem.[12] The problems with pointcuts are deemed intractable. If one replaces the quantification of pointcuts with explicit annotations, one obtainsattribute-oriented programming instead, which is simply an explicit subroutine call and suffers the identical problem of scattering, which AOP was designed to solve.[12]
Manyprogramming languages have implemented AOP, within the language, or as an externallibrary, including:
{{cite web}}: CS1 maint: archived copy as title (link){{cite web}}: CS1 maint: bot: original URL status unknown (link){{cite journal}}:Cite journal requires|journal= (help)| Concepts |  | |
|---|---|---|
| Languages | ||
| International | |
|---|---|
| National | |
| Other | |
