Understanding Aspect Oriented programming (AOP)

Aspect Oriented Programming (AOP) allows modularization of crosscutting concerns such as transaction management, Security, Logging etc. In other words, AOP aims at increasing modularity of the application, by separating the crosscutting concerns from the actual business logic implementations. Crosscutting concerns are nothing but the functionalities that are not actually a part of your problem domain, such as logging.

Why do we need AOP when OOP is already there?

Suppose, there are three classes, A, B and C. Each class has it’s own business methods and I want my logging method to be called at the start and successful end of these methods. What can I do? I will definitely add calls to the log method at required places. If I have a separate Logger class, I will have to instantiate the class everytime inside class A, B and C, to call it’s log() method. This has now led to extra dependency on the Logger object, though it does not add any business value when called from inside any of the business methods of any of the classes A, B and C.


Any change in the method signature (Method signature is part of the method declaration. It is the combination of the method name and the parameter list), might require a corresponding change in all the classes A, B and C, wherever the Logger method call has been done. These unnecessary dependencies inside the classes finally gave way to Aspect Oriented Programming. AOP not only removes these unnecessary dependencies, but it also increases application modularity and provides us with easily configurable handle inside spring context XML.

How does AOP work?

Let us take the same scenario as I have explained above. Suppose, there are three classes, A, B and C. Each class has it’s own business methods and I want my logging method to be called at the start and successful end of these methods. Now, with AOP concept into picture, I create a new class LoggingAspect instead of the conventional Logger class. For now, assume LoggingAspect is a class with some extra privileges (We will be going with the actual implementation and examples later). With LoggingAspect, I do not need to instantiate LoggingAspect inside any of the classes A, B or C, to call it’s log() or any of the equivalent method.

With AOP, I have an Aspect Configuration as well, that is done inside any of the Spring context XMLs. Aspect configuration specifies which objects/methods the aspects should apply to. Since everything runs inside the Spring container, Spring read this aspect configuration, and executes the configured aspects on the concerned methods/objects. Spring makes sure the configured aspects are called before/after the methods that have been configured.

An XML based aspect configuration looks something like the following:

Spring AOP

Each of the comments in the snapshot have their explanation as you go ahead.

Adding the same above snapshot below with some additional comments:

Spring AOP 2

The same AOP configuration can be very well achieved with AspectJ Annotations. Equivalent AspectJ implementation with annotation will be like:

Note: To use the annotations, we need to integrate Spring with AspectJ.

There are a few AOP terminologies that needs to be kept in mind.

Aspect: Aspect is the modularization of a concern that cuts across multiple objects. Logging and Transaction management are the best examples of cross-cutting concern in Java. In Spring AOP, aspects are implemented using regular classes (the schema-based approach, with XML based configuration) or regular classes annotated with the @Aspect annotation (@AspectJ style), for which AspectJ needs to be integrated with Spring.

Join Point: In Spring AOP, a Join Point always represents a method execution. This represents a point in your application where you can plug-in AOP aspect. You can also say, it is the actual place in the application where an action will be taken using Spring AOP framework.

Advice: Action taken by an Aspect at a particular join point.  Different types of advice include “around“,”before“, “after“, “after returning” and “after throwing” advice. Around advice is the most important and powerful of all, where the advice code gets executed before and after the execution of the JoinPoint methods. It is the responsibility of around advice to invoke the join point methods, and finally return the respective values if the JoinPoint method returns any.

Pointcut: Advice is associated with a pointcut expression and runs at any join point matched by the pointcut. That means, in the above example, the expression (“execution(* com.jcombat.customer.bo.CustomerBo.addCustomer(..))”)
is the pointcut and the corresponding matching set of methods, to which the LoggingAspect needs to be applied, is the Join Point. In other words, you can say that, set of Join Points is called a PointCut.

Target object: The object that is being advised by one or more aspects. Also referred to as the advised object.

Weaving: Weaving is the process of linking aspects with other objects to create an advised object. This can be done at compile time, load time, or at runtime. Spring AOP performs weaving at the runtime.

There is something great with AOP proxies getting created in the process. For any of your queries, we would be as glad to help you.

Receive our updates to your inbox

Get more stuff like this
in your inbox

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.