The definition of AOP in wikipedia seems a little bit difficult for beginners to understand, so in this blog I use an example to introduce why we need it.
Suppose I have an order command class which performs its core business logic in method doBusiness:
In method execute(), it is flooded with too many non-functional code like logging, authorization check and performance trace.
It is not a good design, we can try to improve it via template method pattern.
Template method pattern
With this pattern, I create a new parent class BaseCommand, and put all non-functional code inside the executow the real business logic is defined in child class OrderCommand, whose implementation is very clean:
Drawback of this solution: as the parent class has defined the template method execution, it is NOT possible for a child class to adapt it, for example, a child class cannot change the order sequence of authorization check and performance trace method. And suppose a child class does not want to implement authorization check at all – this could not be achieved with this solution. We have to use decorator pattern instead.
Decorator pattern
First I need to create an interface:
And create a decorator to cover the log and authorization check function:
And a second decorator for performance trace:
And the class to finish the real business logic. Now I have the full flexibility to constructor the instance according to real business case, with the help of different decorator. The following instance fullCmd owns the ability of both authorization check log and performance trace.
Suppose in a given scenario, only performance trace is needed, we can just use the performance trace decorator:
Drawback of decorator pattern: The decorator class and the business class have to implement the same interface, command, which is more business related. Is there possibility that the utility classes for non-functional implementation can just work without implementing the same interface which is implemented by business class?
AOP solution
I use a Java project implemented by Spring framework to demonstrate the idea.
Suppose I hope to add performance trace on this business method: save
1) You may have already observed the annotation @Log(nameI042416=”annotation for save method”) used in line10.
This annotation is declared in file Log.java:
(2) Now I have to declare an Aspect class which contains a pointcut. A pointcut tells Spring framework which methods could be applied with AOP strategy, and the class annotated with @Aspect contains methods which should be called by Spring framework to “decorate” the methods identified by annotation. Here below I have declared a pointcut “logJerry” via annotation @Pointcut:
For example, since we have annotated the business method save() with “@Log(nameI042416=”annotation for save method”)”,
we can define what logics must be done on it, with the help of @Before and @After plus declared pointcut.
With this approach, I can add performance trace function to save method without modifying its source code.
Set breakpoint on these beforeExec and afterExec methods, launch the project with Tomcat under debug mode, paste the following url to your browser:
http://localhost:9498/springaop/aopRootJerry/aop2Jerry/i042416?string=sap
Through callstack you can understand how the AOP call is working in Spring.
Why we say AOP can increase modularity by allowing the separation of cross-cutting concerns?
Suppose we have lots of methods all of which need common utilities like log, performance trace and authorization check. Before we use AOP, these utilities are scattered in every method:
After AOP is used, those common stuff are extracted into Aspect class and reusability is fulfilled. From the picture below we can see the cross-cutting concerns are now separated.
