The goal of AOP is to address cross cutting concerns. You usually have these cross cutting concerns when you are building a big application that is built on top of different modules built by different programmers. When you have this situation you can probably expect that unless programmers coordinated their efforts on identifying common elements in their programming for the modules, that you will have cross cutting concerns. Other situations might crop up that might lead to cross cutting concerns, but this is especially one of common ones.

What I found as a drawback with AOP is the spaghetti code that those precompilers output.

I would agree that AOP is best for cross-cutting concerns: functionality that touches multiple layers and/or multiple modules within those layers. Logging, of course, but also caching, authentication, exception handling, transaction management, etc. Are there any specific cases where you aren't sure where you'd want to use AOP or not?

@Arturo: Which AOP tool(s) are you using that are *pre*compilers? I've found that tools like PostSharp, Castle DynamicProxy, etc do their work as *post*compilers. By necessity, those tools combine concerns together, which fits a loose definition of "spaghetti", but it's not been so bad that it's unreadable (not that I have to read it that often, since it's post-compile).

Matthew,

I did some work using aspect C (would have to look for the specific one I used) and it was somewhat unreadable since due to generic variables you had to shift back and forth between the original code and the output by the aspect C code. Maybe they have gotten better but at the time I used it it was substantially cumbersome.

Hi, I posted nice description on AOP-MDD-GP differences in here: http://link.springer.com/article/10.1007/s10586-015-0471-7 supplemented with images.

Here direct answers to each part:

> aspect oriented programming (AOP) is fixing problems on object oriented  programming (OOP) although its not as fast as OOP.

You must think that OOP address most of existing problems effectively by separating out concerns. For instance it is clear we want to separate our User Interface from Data model, right? But there exists a special group of concerns (information that impact your source code) that cannot be separated from others. Examples are business rules, transactions, performance optimisations, security. And these cross-cutting concerns are not effectively separable by OOP. You can capture them but ineffectively, tangling your code. 

AOP suggest to consider OOP components and Aspect as two different modules. Thus you gain multiple dimensions to separate your concerns/problem - multidimensional functional decomposition ;). These components describe plain application and Aspect can be seen as extensions to it that activate under different conditions at different locations in the component code. For this purpose AOP introduces join points. What is a join point? A place in the code - method name, parameter, annotation, context, etc. The way aspect weaver connects component and aspect is that it parses the component code - and builds up a join point representation. Then it lets, say considers your current program execution or context to determine whether it it should consider certain aspects. For example you call a method annotated @Secure and it integrates security aspect to determine whether current user can access the method.

AOP is not the only approach to separate cross cutting concerns, you can look for Generative Programming or Model-driven development, or even Domain specific languages. On the other hand the AOP has the best formalisms. 

You get AOP because you need to improve maintenance. Performance can be as good as OOP, since you can apply AOP at compile time ;).. My experience at runtime is impacting performance by 5% but this strongly depends on problem nature ;)

>How do you decide between using AOP or OOP based on your experience?

Does OOP structural decomposition lead to tangled code? Did you try Visitor pattern, command or template method and non works? then you go for AOP

There are clear domains for usage of AOP - security, business logic, validation, transaction and user interface.. many to come with research ;)

Interested in User Interface? See this free article http://cs.baylor.edu/~donahoo/papers/CCD+14.pdf

http://cs.baylor.edu/~donahoo/papers/CCD+14.pdf

http://link.springer.com/article/10.1007/s10586-015-0471-7

Article Aspect-driven, Data-reflective and Context-aware User Interf...

Article On separation of platform-independent particles in user interfaces