AOP – Aspect-Oriented Programming
AOP is a technology well designed to solve many common problems that programmers encounter on their way to make a good, working code in J2EE. Spring offers AOP technology to complement IoC feature and confirm that the enterprise services codes are not polluting your application codes.
To keep everything in Spring architecture design, its AOP features are separated form core IoC container. You don’t have to use AOP technology with Spring, but most of the users choose to keep using it within Spring, only to use full potential of “out-of-the-box” services provided by framework.
Spring takes a specific approach to AOP. You can use as little AOP as you want, or integrate it with J2EE to harness the power of AOP extensions to the Java language. When learning how to use the full power of AOP, which is most likely to take the industry years, Spring enables incremental adaption of AOP without the risking of dragging the projects to the “mountains edge”. I recommend that you take some time to understand the basic rudiments of this important technology, which can help you solve practical problems more easily.
There is no need in performing a special compilation path or instrument the class loader at runtime. But the build and deployment process are the same as in a plain Java application.
It is possible to proxy any object, no matter of what language it is implemented or used in. Remember you can use Spring's support for scripting languages to implement any managed object in any language, yet still be able to unleash the full power of Spring AOP to your scripted objects.
It enables you the use of different advice for multiple instances of the same class. This is very difficult or even impossible with byte code modification approach, but is sometimes very useful in diffcult compilations.
It is very easy to understand in conditions of the Proxy and Decorator design patterns.
It does not affect at all the target object. The target object itself will behave the same way before or after using Spring AOP.
It's possible to create a proxy programmatically, simply by creating it in class library style.
The negative consequences are that:
Spring AOP is limited to method interception. While Spring's API design is like the AOP Alliance APIs it uses, it would allow for other types of join point to be advised, when Spring AOP is likely to stay focused around returning its core value proposition well. For example, it is not possible to advise field access or object creation.
It is possible only to proxy explicitly. Objects will not be automatically proxied when created by the new operator; proxies must be created programmatically. This is the most significant limitation. However, as Dependency Injection provides such compelling advantages in general, your enthusiasm for the new operator is likely to wane significantly when working with an IoC container such as Spring, PicoContainer, or HiveMind.
Targets are not aware of being proxied. This is usually means a good thing, but it also does mean that if a target object request a method on itself, the request will not be advised.