In programming, aspects are cross-component relationships. Aspect-oriented programming (AOP) introduces aspects as separate syntactic structures and thus increases the modularity of object-oriented (OO) programs with respect to these aspects.
Aspects are unavoidable in complex systems and define an explicit area of responsibility. By having a clear structure, aspects have a specific set of methods that cross the boundaries of components and are used in specific places. The separation of the semantics of an application from the technical details such as error handling, persistence, validation or security is seen as an advantage of aspect-oriented programming. As disadvantages an increase of the overhead in the generated program code or also losses in the performance of an application to be derived from it are called.
The concept of aspect-oriented programmingThe concept of aspect-oriented programming is based on the work of Gregor Kiczales at the company Xerox, Palo Alto Research Center. There, the first aspect-oriented language was developed with AspectJ as an extension of the Javaprogramming language, before its further development was then transferred to a project of the Eclipse organization. In the meantime, however, there are also corresponding aspect-oriented implementations for other programming languages such as Python, C++ or PHP.
The objective of aspect-oriented programmingThe objective of aspect-oriented programming is the clear separation of components and aspects (also called concerns). One speaks in this connection also of the fact that aspects intersect components - or if necessary also other aspects - crosswise. In this context, a component in the sense of AOP is a system property that can be encapsulated in a generalized procedure. In contrast, an aspect is a system property that cannot be encapsulated in a generalized procedure. Examples of aspects are functionalities of persistence, security, logging, or logging procedures that, following the object-oriented approach, are continuously encapsulated in the individual classes. Thus, the code is redundant and this is called code scattering. The combination of code and aspects that have nothing to do with the actual task of the component is called code tangling. If, for example, the requirements for one of these aspects change, all classes concerned must be adapted - this clearly contradicts the principle of reusability.
The mechanism of aspect-oriented programmingThe mechanism, as the AOP uses it, is in the broader sense already well-known in connection with the subjective programming. In the literature in connection with the component-spreading aspects also frequently one speaks of so-called Crosscutting Concerns. In aspect-oriented systems, these are not incorporated separately into each class concerned, but are initially implemented in isolation. The connection to the actual, application-related program code takes place automatically via the programmed aspects. A distinction is made between dynamic and static crosscutting. This process of manipulating classes is also called weaving the aspects into the program code.
In the following, the basic advantages as well as the disadvantages of AOP are compiled, whereby only the essential advantages are presented here without explicitly considering their possible interactions:
Responsibility each module is assigned a clear area of responsibility.
Modularization By avoiding scattering and tangling, the program code is better modularized. This results in reduced redundancy, increased comprehensibility, and ultimately more maintainable software. The argument of the reduced program code is contradicted in the literature just as frequently, even if this thought can be followed intuitively quite. Ultimately, however, the reduction of code redundancy will probably depend on how many components an aspect "cross-cuts". The higher the number of cross-cutting components, the more scattered code can be reduced.
Simplicityarchitecture and design can focus on the requirements of the application itself. The extreme programming approach also follows this principle for simplicity of design.
Reusability Aspects are less tightly coupled to an application by their approach than is the case with conventional programming. Therefore, aspect-oriented code generally has good reusability.
Stability: Because crosscutting concerns are less likely to be overlooked when implementing more application-specific functionality, the code is more stable overall.
Cost: Simplicity, reusability, and stability have a lasting positive impact on cost. In addition, the system can be used sooner, and thus the costs of development are amortized sooner.
However, these advantages are also offset by practical disadvantages:
Debugging Due to the separation of code and process structure, the control flow in a program can only be followed with difficulty. The problem is comparable to dynamic binding in object-oriented programming.
Performance When weaving at runtime (dynamic weaving), reductions in performance can be observed. With static weaving, these can only be realized to a limited extent.
Encapsulation AOP breaks the object-oriented principle of encapsulation, since a class no longer has its entire behavior under its own control.
Coupling So-called pointcuts are predominantly defined by names of classes, methods, variables or even packages. This results in a coupling of components and aspects and leads, among other things, to the requirement of strict adherence to naming conventions.
Discipline The application of AOP requires adherence to software standards, not only with respect to naming conventions, which can be difficult in larger development teams.
Some of the terminology used in AOP has different connotations-for example, "non-functional requirements" are often equated with crosscutting concerns, which is clearly incorrect. Or in other publications, aspects are already referred to in the requirements phase. Provided that minor deviations are observed, aspects can be modularized according to similar criteria as components. This places aspects and components below the term module. In the implementation of AOP, AspectJ is the most advanced and universal of all approaches. In the earlier stages of development, there is a wide variety of different approaches. With regard to the specification language, the Unified Modelling Language (UML) is one option.