I am a newbie in the area of AOP. The first time I coded something applying concepts of AOP, I was thrilled to understand how aspects eliminate cross cutting patterns in your application. I was overwhelmed by the thought of solving cross cutting patterns like security, logging, transactions, auditing and etc applying AOP.
However, when I first proposed usage of AOP to the client I am working for, I was told that they don't support it. I was told that AOP means more maintenance! Your pointcuts have to change if your code changes. Hence, you might have to analyze, change and test your aspects whenever you change the code to which they were applied?
What do you have to say regarding this? Why are mainstream companies not open yet to extensive usage of AOP? Where is the AOP world going?
views:
547answers:
6AOP is a relatively new concept, and large companies are generally wary towards new concepts. They fear getting stuck with a lot of AOP code and unable to find people who can maintain it.
Regarding the specific criticism, it seems uninformed or misunderstood. The whole point of AOP is to reduce maintenance work by reducing code duplication in the area of cross-cutting concerns. However, it is true that it can make maintenance more difficult by making it harder to understand the the code - with AOP, when you look at a particular piece of code, there's always the chance that an aspect defined somewhere else completely changes its behaviour.
Personally, I'm not sure the benefits of AOP (are there really that many cross-cutting concerns?) outweigh this problem. The only way to I can see to solve it would be through support in IDEs; but making you even more dependant on an IDE isn't such a great thing either.
The trend seems to be towards app servers and frameworks that address specific, important cross-cutting concerns like transactions and security in a similar manner as AOP (i.e. central declarative definition) but without giving you its full power to confuse maintenance developers.
AOP is one of those things that's an interesting idea that just doesn't work all that well in practice. Java's had AOP available for a decade or more now, and it's not being used much because it seems to introduce more problems than it fixes.
I had to do some performance optimisation on an application and I chose to write a custom profiler in AspectJ. I was skeptical about using AOP at first but I realised that it was absolutely the perfect tool for the job.
However, there are many jobs that I would not use it for. I would be very wary about using it for anything that may affect application functionality. The extra layer of indirection and lack of transparency would cause too many problems for developers trying to add features or fix bugs.
People forget that Java annotations and their use in frameworks like Guice and Spring were inspired by AOP. I would say Java annotations is where AOP is going today.
We use AspectJ AOP implementation and are very happy with it. You should consider it just another part of your toolkit that makes some concepts easier to express then in 'normal' java. We currently use it mainly to provide JMX interfaces to our services.
It is true that more IDE's should support it (I'm looking at you JetBrains!), that would certainly help the adoption.
I was told that AOP means more maintenance!
That's just silly and exactly wrong. AOP is an essential tool for getting noise out of your code and allowing you to focus your effort on delivering business value. When the business rules change you don't have to wade through miles of framework logic to reflect the new changes in your code.
Like any tool though, you have to make sure to use it correctly. I had work around the fact that my AOP logging would inadvertantly log decrypted credit cards:
http://www.agileatwork.com/what-happens-when-you-actually-use-aop-for-logging/