Understanding Spring AOP [closed]

Answer 1

AOP is a way to modify existing classes in a code base to embellish them or change their behavior based on rules defined separately. This modification can be done before the classes are put into a jar/war, or can happen dynamically while the code is being loaded.

The idea is, rather than finding all the points of code that you want to modify in the source code and hand modifying them, you define rules for how to find points of interest in the code base, and what embellishments you would like to do to them. These rules are called aspects (the A of AOP).

The prototypical example is you want to get some timing information on various methods in your code base. You could go find all the methods of interest and at the top put a call to

long start = System.currentTimeMillis();

and at the end do

long end = System.currentTimeMillis();
System.out.println("Method time is: " + (end - start));

but that is:

1. probably a bunch of work
2. temporary, and you don't want to muck up your code base

You can instead define aspects that say what methods you want to modify, and that you want to do stuff at the beginning and end of these methods.

When the AOP is applied, either at jar creation time, or class loading time, it's as if you wrote the classes that way originally.

Answer 2

AOP enables cohesive development by separation(module) of Cross Cutting Concerns into Aspects. Put it simple, it’s just an interceptor to intercept some processes, for example, when a method is execute, Spring AOP can hijack the executing method, and add extra functionality before or after the method execution.

For example: Logging, Transaction and security are some Aspects. In Logging we may have different aspect i.e. time calculation logging, simple in and out message logging and so on..

• Advise defines what needs to be apply.
• Joinpoint is where an Advice is apply.
• Pointcut is a combination of different Jointpoints.
• Aspect is applying an Advice at Pointcuts.

Note: Spring does not support AOP for methods marked as final.

Source

---

AOP works like Object Oriented Programming. In Object Oriented Programming, the unit of modularity is Object But in Aspect Oriented Programming the unit of modularity is Aspect. Aspect works as the modularization of concerns known as crosscutting concerns in AOP. AOP framework is pluggable in spring. AOP provides declarative enterprise service and allows users to implement custom aspects.

Source

---

Spring provides declarative programming with AOP. This is a better way to implement cross cutting concerns without the needs to use plumbing code all over the core business classes. AOP enables you to think about concerns or aspects in your system. Typical concerns are transaction management, logging etc. AOP enables you to capture the cross-cutting code in modules such as interceptors that can be applied declaratively wherever the concern they express applies. Spring includes a proxy-based AOP framework.

Source

Answer 3

Aspect Oriented Programming is sensibly new and it is not a replacement for Object Oriented Programming. In fact, AOP is another way of organizing your Program Structure.

To be more clear I will use some diagrams:

1. What is Aspect?

   |---------------------|------------------|------------------|
   |      Aspect         =     Point cut    +  Advice          |
   |---------------------|------------------|------------------|
   |                     | Where the aspect | What code is     |
   |                     |  is applied      |  executed.       |
   |---------------------|------------------|------------------|
   

   Aspect = Point cut + Advice

2. Type of Advice methods

3. Aspect Example

   @Around( "execution(* *(..))" )
   public Object trace(ProceedingJoinPointproceedingJP)throwsThrowable{
       String methodInformation= proceedingJP.getStaticPart().getSignature().toString();
       logger.trace("Entering "+methodInformation);
       try{
           returnproceedingJP.proceed();
       } catch(Throwable ex) {
           logger.error("Exception in "+methodInformation, ex);
           throw ex;
       } finally {
            logger.trace("Exiting "+methodInformation);
       }
   }
   

Answer 4

AOP is a pattern used to modularize cross cutting features. So if there is a certain "thing" that applies to a significant part in your code then you can use AOP to solve that problem. These "things" are called aspects.

An example below:

An exception logger is used across the enterprise app. So you could set it up using AOP the following way. So now all methods under my.service package will get logged the following way.

  <bean id="exceptionLogger" class="my.good.ExceptionLogger" />  
        <aop:config>
                <aop:pointcut id="allServiceMethods" expression="execution(* my.service.*(..))" />
                <aop:aspect id="serviceLogger" ref="exceptionLogger">
                    <aop:after-throwing pointcut-ref="allServiceMethods"
                                        method="logIt"
                                        throwing="e"/>
                </aop:aspect>  
        </aop:config>

And the ExceptionLogger class could be something like below:-

public class ExceptionLogger {
    private static Logger logger = Logger.getLogger(ExceptionLogger.class);
    public void logIt(JoinPoint jp, Exception e) {
        StringBuilder msg = new StringBuilder();
        msg.append("<whatever makes sense>");
        logger.error(msg.toString());
    }
}

Also take a look at this relevant question:-

1. What is the most common use for AOP in spring project

Answer 5

In a nutshell, AOP is a mathematician's way of explaining how you should organize your code neatly to avoid having a particular functionality scattered in bits and pieces across lots of modules or object. At its heart, AOP is a good thing whether or not it is called AOP.

But you are faced with a specific AOP implementation and need to figure out how to use it. I think the best way to do this is to look for blogs where people post recipes and examples of how they are using it with Spring. This way you bypass the mathemeticians and get to read the writings of engineers who are more in touch with reality.

There are two kinds of computer scientists, mathematicians who delight in the obscure and use tortured terminology to explain simple things, and engineers who will tell you step by step how to build software. Working programmers tend to be more of the engineer mindset because abstract thinkers find it hard to handle the long slog of gaining experience. That's why you find AOP hard to understand. Not because it is hard to understand, but because it is explained so poorly by abstract mathematical thinkers who are not terribly familiar with "plain English".

I wonder what would happen if an AOP guru sat down with a Function Point Analysis guru.