3

Aspect Oriented Programming (AOP) seems like an interesting concept. At first I was pretty enthusiastic about it, but as I read more and saw the use cases people were describing I grew disappointed.

A lot of sites I saw, plus a presentation from the developers of AspectC++, presented use cases that I found rather dubious.

They talked about how AOP can be used to do error handling (throwing exceptions), do bounds checking on parameters and return values, return safe null objects in case something goes wrong, security, etc. Are these just bad examples (and not actual use cases), or am I missing something?

How are you supposed to be aware of what's happening when you call a function? Virtually anything can happen, depending on what aspects you decide to apply. Isn't that going to mess up things really really badly? What about API documentation, how am I supposed to write that?

So far the only good use cases for AOP I've seen are things like logging or profiling — things that don't influence the actual logic flow and serve only as debugging tools.

Is AOP useful for anything else other than debugging mechanisms?

Wayne Conrad
  • 103,207
  • 26
  • 155
  • 191
Paul Manta
  • 30,618
  • 31
  • 128
  • 208
  • possible duplicate of [Do you use AOP? and what for?](http://stackoverflow.com/questions/382789/do-you-use-aop-and-what-for) – Matt Ball Sep 27 '11 at 17:36
  • 2
    I think [Do you use AOP? and what for?](http://stackoverflow.com/questions/382789/do-you-use-aop-and-what-for) is more about example uses and this seems a bit more about theory and effects on code quality. – Jared Sep 27 '11 at 17:45

1 Answers1

4

AOP is most useful when you have concerns that aren't relevant to the main concern of your application (called orthogonal concerns). It can be super handy when you have to add a concern to existing code (say security to something that was built for internal private use) or have to add functionality that for whatever reason just doesn't fit into your domain model without really obscuring your business logic.

I wouldn't use it anywhere you have to wonder what is happening when you call a function. That seems like code smell to me.

Jared
  • 1,450
  • 1
  • 13
  • 25
  • 1
    I agree with your last statement, but I'm not sure about the others. Using AOP to add security is just patchwork. Also, security is an important part of a program, you can't just swap it in or out without consequence. From what I've seen, AOP is great for 'unimportant' things that don't really affect your behavior if you turn them off; and hence, since they don't affect your behavior, you'd like them to be separated from the actual logic. – Paul Manta Sep 28 '11 at 07:46
  • Well, what I was trying to get across is a situation where the application already exists and wasn't secured (like an old internal line of business application, maybe something a department developed internally) and you had to add security well after the fact. It might not be feasible (economically perhaps) to redo the framework of the app but you could add security with AOP at this point. I would never start out that way personally. – Jared Sep 28 '11 at 19:21
  • 1
    @mgroves goes on about AOP all the time. http://mgroves.com/ He's sold on PostSharp. However, I've yet to really find a use for AOP in a well designed framework that wasn't already served. When pipelining of events happens, you can always just into the pipeline and do what you need instead. AOP is very magic, not even convention over configuration. Magic is bad in code, someone later won't be able to tell why a behavior exists easily. – Travis Sep 28 '11 at 19:27