should I use aspects?

October 21st, 2005

I know I blog about my current problems and observation, but that is what blogs are for, not?

My favourite project at work I consider already as a bunch of legacy code (not line is older that 18 months I think). A collegue labelled it yesterday as a “nice prototype” that grow a little bit too much. Well, I must admit he has a point. Design is simply non-existant (besides some small areas) or went in directions that haven now been proven to be dead-ends.

Two “aspects” are hot now: Logging and Security (I prefer to talk about Privileges). Logging was introduced by old-fashioned instrumenting (aka manually inserting logging-code). Pretty incomplete and all but flexible.

Privileges are “designed in”, but not in all necessary places. I am tempted to use Aspects to implement them for some important “point-cuts”, but I am hesitating.

First of all I am concerned that introducing AOP would open Pandora’s box. We have (yes we are doing code-reviews… but don’t ask) f**king lot of abuse of our framework and Aspects would open another way of creating incomprehensible non-refactorable code.

In some sense this applies even to my Privilege-aspect idea: If we had decided to use some IoC-container the main problem could be solved with a few lines of code. So the “need” for AOP in my case is simply due to inadequate design or is AOP a design-element?

I sure see good uses of AOP, but it seems not to be always clear when to apply it. A fool with a tool is still a fool, and if you only have / really love you hammer, you’ll do anything with your hammer.