Writing software is a complex business - not only do you have to get the enterprise logic of the application correct, typically you also have to deal with multiple other concerns at the same time, such as "what should happen if something goes wrong", "how should I make sure we know what is happening during execution", "how to …
Jacobson & Ng to the rescue
John Hunt rightly points out:
"It is clear to me that to identify the concerns which should be implemented as an Aspect is not necessarily straightforward nor is it directly covered by traditional software engineering methodologies."
It is indeed difficult. I found Jacobson & Ng's "Aspect-Oriented Software Development with Use Cases" (http://www.amazon.com/dp/0321268881) very useful in helping get to grips with identifying concerns very early in the design. It's very thin on coding but does a grand job of describing the design process using aspects.
AOP - a bad example?
Richard emailed in anonymously with this comment:
A few months ago I decided I was fed up with hearing all the hype about AOP and thought I'd better actually look into it to actually understand it. Now, what really annoyed me about trying to get started in understanding AOP is that the most prevalent example on using AOP concerns logging. In my opinion (and experience) logging is NOT a good area for using AOP. In fact, I have never seen an decent example of how to use AOP. Not to say that one doesn't exist. I'm lead to believe that Spring using AOP behind the scenes for transaction handling, etc.
I don't log entry and exit into methods. If I have a function that I'm not sure is behaving properly I will add debug statements at various points during the method. When I'm logging, it's some value that probably isn't supplied as an input parameter to the method. I'm also concerned that writing AOP-based logging statements has the knock-on effect of doubling the size of your code base.
Having said all that, I have found a suitable application for AOP-based logging in my application. I use it for logging exceptions at the DAO layer with all the information I need. AOP has been very useful in that I have been able (through Spring AOP) to write a short class that can log a method call signature and the generated stack trace. Unfortunately I don't think I can apply it elsewhere right now.
I suppose what I'm trying to say is that it would have helped me to have seen a really useful application of AOP methods to solving a problem because, to me, logging ain't it.
Is exception logging better?
And here is John's reply:
Presenting a new concept and a concrete real world example of how to use that concept in a short column is always a challenge. The logging example was selected as almost everybody has had to put some form of logging into their code at some time or another - and thus it is a common reference point.
In real world applications, it is more likely that the specifics of an application will determine what an appropriate Aspect might be - hence the (very) brief section on generating Aspects. I also suspect that it is only once something has been required a number of times that its use as an Aspect may become obvious.
I find it interesting that the one use of AOP you mention does end up being logging of exceptions - and I personally think this is an excellent example of what can be done with AOP. I also believe that Spring makes quiet extensive use of AOP.
As far as logging method entry and exit goes I have found that with customers’ systems, where it can be difficult to go in and add extra logging, actually being able to turn on entry and exit information (including parameter listing) can be an extremely useful feature - although this can depend on the environment in which one is working