Menu
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?
682
Rest assured that OOP is alive and well, as is Aspect Oriented Programming, Functional Programming and Procedural Programming. One of the signs of maturity in an application developer is being able to recognize the strengths of each style and finding how to use them to provide solutions.
Aspect-oriented programming isolates the concerns of your application, reduces code clutter, and improves the maintainability and readability of your code.
Aspect-Oriented Programming (AOP) complements OOP by providing another way of thinking about program structure. While OO decomposes applications into a hierarchy of objects, AOP decomposes programs into aspects or concerns.
In Spring AOP, aspects are implemented using regular classes (the schema-based approach) or regular classes annotated with the @Aspect annotation (the @AspectJ style). Join point: a point during the execution of a program, such as the execution of a method or the handling of an exception.
AOP 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.
119
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.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
