We have seen that with an object-oriented system, code tangling and code scattering can occur. This can cause the system to have duplicate code and functionalities not being clear and plain. Evident problems with the implementation of further requirements arise, with modules strongly coupled in the implementation.
In the previous situations, the object-oriented system can't be of any help because the following effects occur:
Difficult evolution: A module's implementation is coupled to other functionalities.
Poor quality: In the
TanglingListUserControllerexample, if a problem arises, it's not even clear what the module's main functionality is.Code not reusable: If the implementation involves several concerns, it won't be suitable for other scenarios.
Productivity: Scattered implementations move the problem's main focus to the periphery where the implementations are.
Traceability: Code scattering functionality is implemented at several points. To have a hold on it, you need to check all the modules in which the implementation is spread.
Aspect-oriented programming allows:
The modularization of crosscutting concerns by its constructs
The uncoupling of the modules
Using aspects, the removal of dependence of a crosscutting concern from the modules that use it
Now let's see practically what AOP provides to overcome the gaps in object-oriented programming highlighted so far in the book, and what are its main concepts.
Let's see who are the main actors that enable the aspect-oriented programming, implement the crosscutting concerns in the aspects, and define with other actors the points and the classes on which these crosscutting concerns are applied.
In the following figure, we see the normal interactions between objects:
In object-oriented programming, classes cooperate by calling mutually public methods and exchanging messages.
Crosscutting concerns are placed in the implementations of the classes A, B, and C, and this leads to the problems previously explained such as code tangling, code scattering, and so on.
The following figure conceptually compares the execution flow of the invocation of a method in the case of OOP and AOP:
In the case of object-oriented programming, where the crosscutting concerns are included into the classes' implementations, Object A in its method A invokes method B on Object B. This is, apart from exceptions, the normal flow of messages' exchange between two objects that interact. The cross interactions are called back and used just in these two methods because there isn't any other way to act.
In the flow with aspect-oriented programming, the crosscutting functionalities are extracted from the object-oriented implementations and applied as advices where they are actually useful. This is because they are applied on the flow where they really have to be carried out, that is by the pointcuts and on the target object.
The whole of the advice, the pointcut, the target object, and the joinpoint, make an aspect.
Now let's introduce the AOP terms denoting the components that take part in the implementation, which are partially pictured in the previous figure.
Aspect: Corresponds to the class in object-oriented programming. It's the crosscutting functionality.
Joinpoint: This is the application point of the aspect. It is a point of the execution of a program such as the invocation of a constructor or the execution of a method or the management of an exception (WHEN).
Advice: This is the action an aspect performs at a certain joinpoint.
Advices can be "around", "before", and "after".
Pointcut: This is the expression for the joinpoint's selection, for instance a method's execution with a certain signature (WHERE).
Introduction: This is the declaration of methods or additional fields on the object to which the aspect will be applied. It allows the introduction of new interfaces and implementations on the objects.
Target object: This is the module (Object) to which the aspect will be applied.
Weaving: This is the linking action between the aspect and the objects to which advices must be applied.
This action may be performed at the editing phase using an AspectJ compiler, or at runtime.
If a runtime action is carried out, an AOP Proxy is used to implement the contracts that the aspect has to respect.
Types of advice:
Before advice: This is an advice that executes before a joinpoint, but which does not have the ability to prevent execution flow proceeding to the joinpoint.
After returning advice: An advice to be executed after a joinpoint completes normally.
Throws advice: This is an advice to be executed if a method exits by throwing an exception.
After (finally) advice: This advice is to be executed regardless of the means by which a joinpoint exits.
Around advice: This advice can perform custom behavior before and after the method invocation. It is also responsible for choosing whether to proceed to the joinpoint, or to cut short the advised method execution by returning its own return value or throwing an exception.
In the case of Aspect-Oriented Programming in the earlier image, taking into account that the joinpoint is the invocation of methods and that the joinpoint is the method called methodB, the aspect executes the crosscutting concern included into the advice when methodB is invoked on the target, Object B. This kind of interception before methodB is that of a Before Advice.