This allows behaviors that are not central to the business 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, while aspect-oriented software development refers to a whole engineering discipline.
For example, interceptors that specify the methods to express a limited form of cross-cutting, without much support for type-safety or debugging.
For example, consider a banking application with a conceptually very simple method for transferring an amount from one account to another:[5] 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 transactions to prevent accidental data loss, and logging the operation for diagnostic purposes.
In the program's current version, security-related operations appear scattered 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 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 hypothetical aspect language for UML may have the following JPM: Inter-type declarations provide a way to express cross-cutting concerns affecting the structure of modules.
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 of AspectWerkz in 2005.
[7] This basically implies post-processing, but rather than patching the generated code, this weaving approach subclasses existing classes so that the modifications are introduced by method-overriding.
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] Though it may seem unrelated, in testing, the use of mocks or stubs requires the use of AOP techniques, such as around advice.
[11] Starting in 2002, AspectJ began to provide IDE plug-ins to support the visualizing of cross-cutting concerns.
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 with unforeseen consequences.
One advantage of modularizing cross-cutting concerns is enabling one programmer to easily affect the entire system.
[11][12] For example, compare the COME FROM program:[11] with an AOP fragment with analogous semantics: 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 advices potentially 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".
[13] 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.
"[14] 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.