Aspect-oriented programming
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, 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.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.[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.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.