What are the disadvantages of Aspect-Oriented Programming (AOP)?

Question

What are the possible and critical disadvantages of Aspect-Oriented Programming?

For example: cryptic debugging for newbies (readability impact)

Answer 1

• Poor toolchain support - debuggers, profilers etc may not know about the AOP and so may work on code as if all the aspects had been replaced by procedural code
• Code bloat - small source can lead to much larger object code as code is "weaved" throughout the code base

Answer 2

I would not call it a critical disadvantage, but the biggest problem I have seen is one of developer experience and ability to adapt. Not all developers yet understand the difference between declarative and imperative programming.

We make use of the policy injection application block in EntLib 4.1 pretty extensively as well as Unity for DI and it's just not something that sinks in quickly for some people. I find my self explaining over and over again to the same people why the application is not behaving in the way they expect. It generally starts off them explaining something and me saying "see that declaration above the method." :) Some people get it right away, love it and become extremely productive -- others struggle.

Learning curve is not unique to AOP, but it seems to have a higher learning curve that other things that your average developer encounters.

Answer 3

Maintenance and Debugging. With aop, you suddenly have code that is being run at a given point ( method entry, exit, whatever ) but in just looking at the code, you have no clue that it's even getting called, especially if the aop configuration is in another file, like xml config. If the advice causes some changes, then while debugging an application, things may look strange with no explanation. This doesn't affect only newbies.

Answer 4

I think the biggest disadvantage is using AOP well. People use it in places where it doesn't make sense, for example, and will not use it where it does.

For example, a factory pattern is obviously something that AOP can do better, as DI can also do it well, but the observer pattern is simpler when using AOP, as is the strategy pattern.

It will be harder to unit test, esp if you do the weaving at runtime.

If weaving at runtime then you also take a performance hit.

Having a good way to model what is going on when mixing AOP with classes is a problem, as UML I don't think is a good model at that point.

Unless you are using Eclipse then tools do have problems, but, with Eclipse and AJDT AOP is much easier.

We still use junit and nunit for example, and so have to modify our code to allow unit tests to run, when using priviledged mode AOP could do better unit tests by testing private methods also, and we don't have to change our programs just to make them work with unit-testing. This is another example of not really understanding how AOP can be helpful, we are still chained in many ways to the past with unit-test frameworks and current design pattern implementations and don't see how AOP could help us do better coding.

Answer 5

With regard to the maintenance/debugging argument, aspect-oriented programming tends to go hand-in-hand with all the other aspects of agile software-development practices.

These practices tend to remove debugging from the picture, replacing it with unit testing and test-driven development.

In addition, it may be much easier to maintain a small, clear code footprint with advice than a large, incomprehensible code footprint without advice (the advice being the thing that transforms a large, incomprehensible code footprint into a small, clear code footprint).