The basic idea seems to be that we want to take cross-cutting concerns which aren"t well modularized using object and modularize them. That is all very fine and well.
But the implementation of AOP seems to be that of modifying code from outside of the module. So, for example, an aspect could be written that changes what happens when a particular object is passed as a parameter in a function. This seems to go directly against the idea of modules. I should not be able to modify a module"s behavior from outside of that module, otherwise the whole point of modules are overturned. But aspects seem to be doing exactly that!
Basically, aspects seems to be a form of code patching. It may useful for some quick hacks; but, as a general principle perhaps its not something you want to do. Aspect Oriented Programming seems to me taking a bad practice and raising to a general design principle.
Is AOP a good practice? Are certain programming problems solved more elegantly with AOP?
Aspect-Oriented Programming makes it possible to do certain types of programming that are difficult to do without unnecessarily scattering code throughout your application or library that is unrelated to the primary functions of your software (i.e. cross-cutting concerns). Examples include:
By confining such cross-cutting concerns to a single part of the application, and then referencing these features in the code via attributes, method call interception, or dynamic proxies, you allow the encapsulation of the cross-cutting behavior; this has all of the benefits (i.e. a single modification point) encapsulation would provide anywhere else in your application.
The key point here is that AOP encapsulates behaviour that is 1) common throughout the application, and 2) peripheral to the application's primary functionality.