aspect oriented programming (AOP)
In programming, aspects are cross-component relationships. The aspect-oriented programming( AOP) introduces aspects as own syntactic structures and increases thereby the modularity of object-oriented( OO) programs related to these aspects.
Aspects are unavoidable in complex systems and define an explicit area of responsibility. By a clear structure aspects have a certain set of methods, which cross the borders of components and at certain places are used. As advantage of aspect-oriented programming the separation of the semantics of an application from the technical details such as error handling, persistence, validation or security is regarded. As disadvantages an increase of the overhead in the generated program code or also losses in the performance of an application, which can be derived from it, are called.
The concept of the aspect-oriented programming
The concept of aspect-oriented programming is based on the work of Gregor Kiczales with the company Xerox, Palo Alto Research center. There also with AspectJ as an extension of the programming languageJava the first aspect-oriented language was developed, before their further development then into a project of the Eclipse organization was transferred. In the meantime, however, there are also corresponding aspect-oriented implementations for other programming languages such as Python, C++ or PHP.
The objective of the aspect-oriented programming
The objective of aspect-oriented programming is the clear separation of components and aspects (also Concerns mentioned). One speaks in this connection also of the fact that aspects components - or if necessary also other aspects - cross-cut. A component is in the sense of the AOP a system characteristic, which 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, which are continuously encapsulated in the individual classes following the object-oriented approach. Thus the code is redundantly present, and one calls this code Scattering. The connection of code and aspects, which have nothing to do with the actual task of the component, one calls code Tangling (diced also disordered code) against it. If for example the requirements change to one of these aspects then all classes concerned must be adapted - this contradicts clearly the principle of the reusability.
The mechanism of the aspect-oriented programming
The 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 of so-called Crosscutting Concerns one speaks. In aspect-oriented systems these are not separately worked into each class concerned but first isolated implemented. The connection to the actual, application-related program code takes place automatically over the programmed aspects. A distinction is made between dynamic and static crosscutting. One calls this process of the manipulation of classes also as weaving the aspects into the program code.
In the following the fundamental advantages as well as the disadvantages of the AOP are arranged. Here only the substantial advantages are represented first, without considering their possible interactions explicitly:
Responsibility Each module is assigned a clear area of responsibility.
Modularization By avoiding scattering and tangling, the program code is better modularized. This has to the consequence a reduced redundancy, the increase of the comprehensibility and finally a software which can be maintained better. The argument of the reduced program code is contradicted in the literature just as frequently, even if this thought can be followed intuitively quite. In the long run the reduction of the code redundancy will probably depend however on how many components an aspect "cross-cuts". The higher the number of cross-cutting components is, 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 of design simplicity.
Reusability Aspects are less tightly coupled to an application by their approach than is the case with conventional programming. Therefore aspect-oriented code is generally well reusable.
Stability By making crosscutting concerns less likely to be overlooked when implementing further application-specific functionality, the code becomes 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 development costs are amortized sooner.
These advantages are however also quite practice-referred disadvantages:
Debugging Due to the separation of code and process structure the control flow in a program can be followed only with difficulties. The problem is comparable with the dynamic binding in the object-oriented programming.
Performance With weaving at run time (dynamic Weaving) reductions are to be comprehended in the performance. With static Weaving these are to be realized only to 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 defined predominantly over names of classes, methods, variables or also packages. This results in a coupling of components and aspects and leads among other things to the demand for a strict adherence to name conventions.
Discipline The application of the AOP presupposes the adherence to software standards not only regarding name conventions, which is connected in larger development teams under circumstances with difficulties.
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 small deviations are considered, aspects can be modularized after similar criteria as components. Aspects and components are thus classified below the term module. With the conversion of the AOP AspectJ is the most advanced and most universal of all beginnings. In the earlier development phases there is a large variety of different approaches. Regarding the specification language with the Unified Modelling Language( UML) a possibility is given.