How to introduce AOP into productive software development?

Question

I know this question has been asked before, but this was one and a half years ago, though I thought it might be the time for a re-questioning. I also recognized it might be seen as subjective, but I guess there are objective reasons for/against AOP.

I would be interested in who is using AOP in software development and also why or why not using it.

I see AOP as a very strong paradigm which can make a lot of development tasks easier. But when it comes to using AOP in real world projects I have made the experience that many decision makers are barely open to it. How did you manage to introduce AOP into your projects?

Previously asked question from August 2008: http://stackoverflow.com/questions/20663/do-you-use-aop-aspect-oriented-programming-in-production-software

Answer 1

We don't use AOP 100% per se but yes we do use whenever we feel appropriate (mostly Spring AOP; that is so nicely integrated with Spring framework)

How did you manage to introduce AOP into your projects?

Well, separate out the cross cutting concerns eg. tracing method calls. In Spring AOP, you can define an aspect (a runtime behavior) which will get applied to a "hooked" section of code. With "hooked" I mean, you should be able to group all the methods where you need this behavior under one common umbrella. At runtime, this umbrella'ed code will get a new behaviour as defined by your aspect.

Answer 2

Our managers listen to their architecture team.

We tell them that AOP is the only solution to implement cross-concern features:

• at a reasonable cost in the first place
• without messing with the functional code written by the development team
• without ever forgetting (compared to manually adding a try-catch to thousands of methods), now and in the future
• without having to train or control what the developers are doing (some are great, others are a real mess)
• with a good maintainability

True, our project is 20 developers and lasted for several years, so there is a huge mass of code. It's the only solution.

I believe the key is to use it only for cross-cutting concerns. If you can code it using regular code, do so. But if it is way too big, then AOP is attractive and justified. Failing to limit AOP would lead to hundred AOP little codes, that would be very hard to understand.

And yes, our software is production-software. Hundreds of clinics depend on it!

Answer 3

Spring AOP as Peakit said is easy to introduce if you are already using Spring framework in your project.

I first added AspectJ for our tools project that is only used internally and never released to customers. This helped both the development team and management to gain confidence on the tool and have a clearer idead about what it can do it for them.