What are best practices for AOP development?

Question

I'm looking for best practices guidelines for developers seeking to learn AOP.

Anything from actual coding techniques to IDE suggestions would be a big help here.

UPDATE: In particular, I'm interested in techniques and guidelines for AOP in C#, Java and Ruby.

Answer 1

Well, AOP is just an idea, you have a lot of ways to achieve it. If you need to have something explicitly called AOP, there are some good implementations available, i.e. classical AspectJ for Java or PostSharp for .NET. But decision to use any of these have to be made carefully. They have quite large learning curve and very often can lead to the code that is some kind of black magic for developers not aware of how AOP is used in a project or not aware of AOP at all.

In C# there are at least two ways to achieve AOP-ish system. First one uses IL modification after the compilation (PostSharp works this way). Second one can be thought as a runtime framework that generates dynamic proxies on your objects (using Castle Dynamic Proxy, Unity Interception from MS Patterns & Practices etc.). Both way have their pros and cons. The second way is much less powerful (you can't interfere with static object structure such as inheritance tree etc.) and has worse performance due to heavy reflection usage. And one can say that dynamic proxy can't be used to do "real" AOP, but for me it allows you to achieve what AOP main goal is - to add custom behaviors to your objects dynamically, without modifying their code, in different places of the system at once. And in my opinion, it is easier to be tested, cleaner, easier to understand, more portable, more flexible.

But after all, I will try to avoid using AOP, especially in newly developed projects. If you are on early development stage, try to design structure that will be easily extensible and modular: use inversion of control, split your logic into loosely coupled modules, work on abstractions and you shouldn't need AOP at all.

Answer 2

The danger with AOP is too much magic - behavior you don't expect running when you don't expect it, and not realizing what's really happening when you look at a piece of code.

1. Try to make the AOP you're using explicit - mark the method being modified. This way when you look at a method or class you know what extra behavior to expect and where find it.
2. If you have global AOP rules, keep them in a central place so you can find them, and have clear guidelines about what you put there.
3. AOP doesn't have to be language-based and doesn't have to modify actual methods. If you're developing a framework for your application, add well-defined hook points where code can be injected and modify the behavior. This can often result in very clean injection that reduces confusion.
4. AOP lets you reduce duplication very elegantly, but you'll always eventually get tripped up by unexpected behavior here and there. When you do, stop and think how to reduce the confusion. Accept the fact that this can mean removing some behavior from an aspect and using more pedestrian programming techniques instead.

"A." has mentioned techniques for injecting behavior in Java and .NET projects.

In dynamic languages like Ruby or Python the built-in metaprogramming features should give you as much AOP as you need. Check out the Ruby metaprogramming tutorial for example.