Aspects are a way the framework intercepts method calls and possibly alters the execution of methods. You can affect the execution of specific method calls you select. This technique helps you extract part of the logic belonging to the executing method. In certain scenarios, decoupling a part of the code helps make that method easier to understand (figure 6.1). It allows the developer to focus only on the relevant details discussed when reading the method logic. If you don’t use aspects carefully, you might end up with a less maintainable app, which is quite the opposite of what you want to achieve. This approach is called aspect-oriented programming (AOP).

Another important reason for learning aspects is that Spring uses them in implementing a lot of the crucial capabilities it offers. Understanding how the framework works can save you many hours of debugging later when you face a specific problem.

How aspects work in Spring

An aspect is simply a piece of logic the framework executes when you call specific methods of your choice. When designing an aspect, you define the following:

• What code you want Spring to execute when you call specific methods. This is named an aspect.
• When the app should execute this logic of the aspect (e.g., before or after the method call, instead of the method call). This is named the advice.
• Which methods the framework needs to intercept and execute the aspect for them. This is named a pointcut.

With aspects terminology, you’ll also find the concept of a join point, which defines the event that triggers the execution of an aspect. But with Spring, this event is always a method call.

The bean that declares the method intercepted by an aspect is named the target object:

But how does Spring intercept each method call and apply the aspect logic? As discussed earlier in this section, the object needs to be a bean in the Spring context. But because you made the object an aspect target, Spring won’t directly give you an instance reference for the bean when you request it from the context. Instead, Spring gives you an object that calls the aspect logic instead of the actual method. We say that Spring gives you a proxy object instead of the real bean. You will now receive the proxy instead of the bean anytime you get the bean from the context, either if you directly use the getBean() method of the context or if you use DI. This approach is named weaving:

In the next figure, you find a comparison between calling the method when it isn’t intercepted by an aspect versus an aspect intercepting the method call. You observe that calling an aspected method assumes you call the method through the proxy object provided by Spring. The proxy applies the aspect logic and delegates the call to the actual method.

Implementing aspects with Spring AOP

Suppose you have an application that implements multiple use cases in its service classes. Some new regulations require your app to store the time it started and ended for each use case execution. In your team, you decided to take responsibility for implementing a functionality to log all the events where a use case begins and ends.

Implementing a simple aspect

In this section, we discuss implementing a simple aspect to solve our scenario. We’ll create a new project and define a service class containing a method that we’ll use to test our implementation and prove the aspect we define works as desired in the end.

In addition to the spring-context dependency, for this example we also need the spring-aspects dependency.