The Underlying Value of Aspect-Oriented Programming [closed]

Question

I recently got into PostSharp, an AOP tool for weaving in code. I've been finding a lot of resistance with other developers over giving up writing code to perform the tasks the weaving was meant to simplify. For instance, I'm finding logging or error-handling code where I have postsharp already doing that. I can understand why its happening, since its hard to remember everything that weaving was setup to do (I'm applying a global attribute definition).

With that said, factoring in levels of experience, etc, is AOP beneficial to a project? What is your opinion?

Thanks.

Answer 1

AOP is beneficial to the project if you have several members of your team possessing extensive experience with AOP. Otherwise you are going to get a very odd mixture of AOP + OOP + Procedural code. My recommendation is to rely on AOP for logging and/or error handling to prove to the team that it is important and functions as expected. Additionally it can teach them proper techniques for writing the layers that are important, for example if they do the error handling wrong during testing the application will blow up, which is what you would want to happen.

Answer 2

As of my understanding of AOP, it should not require several team members with extensive experience. If used right (i.e., do not over-use) and properly introduced to the team, the intended gain in code readability and productivity should be obvious to everyone.

You should find a way to introduce a compendium of the aspects you provide, so that every team member can find information regarding the aspects and their functionality easily.

Although I never used it, I find the idea of caching via aspects appealing. There are many blog posts regarding this one, and I think there is an example of it in the postsharp distribution.