Another week, another weekly concerns.

• Reza Ahmadi uses PostSharp to create a timing aspect.
• Part 1 of a series on AOP in Java with Spring.
• AspectJ with Scala from Jonas Boner.
• Some ramblings about using AOP in gaming.

As far as AOP goes, there's not a great selection of books out there. I've only found 3 that might be worth reading (I haven't read any of them yet):

• AspectJ Cookbook by Russ Miles, published by O'Reilly in December 2004. From the reviews, this seems to be a "how" book, and very specific to AspectJ.
• AspectJ in Action by Ramnivas Laddad, published by Manning in July 2003, second edition in October 2009. This may be the most popular book on AOP, even though it's focused on AspectJ.
• Using Aspect-Oriented Programming for Trustworthy Software Development by Vladomir O. Safonov, published by Wiley in May 2008. I only discovered this one recently. The author of this book is also the creator of Aspect.NET, but apparently it mentions other AOP tools as well. The price tag is a little steep, and since it was written by a professor, I'm guessing it will be very academic and dry.

That's pretty much it. Two books for Java developers from the mid 2000s, and one book for .NET developers from 2008. Am I leaving anything out? I know other books touch on AOP (like Clean Code by Robert C. Martin, which I highly recommend), but not many that really dive deeply into it.

I came across an abstract and slides (PDF) about using AOP to detect code smells. It got me thinking: is clean code and SOLID architecture itself a cross-cutting concern? Usually "good, maintainable code" isn't ever written down explicitly as a requirement (functional or otherwise); it's just sorta assumed that developers will write the best code they can. Obviously that doesn't always happen, and the customer probably won't know one way or the other until after release.

As a developer, sometimes it's hard for me to be objective when looking at my code and the choices that I've made. Pair programming is  one way to help alleviate this: I can get instant feedback from another developer as I'm coding and making decisions. Test driven development also helps, by forcing me to write code that's easy to test (and therefore loosely coupled). Not every project or code base has the luxury of either of these things: maybe there's only 1 developer, or maybe it's a legacy code base. Whatever the reason, another approach to take is code analysis: code metrics like cyclomatic complexity and maintainability index. There's also heuristics, aka "code smells" that (not always, but usually) indicate that there might be a problem.

There are three code smells addressed by the Juliana Padilha's slides, none of which I've heard before:

• Divergent change: this sounds like the opposite of Single Responsibility. I.e. the class has more than one reason to change, and thus its responsibility is diverging.
• Shotgun surgery: I've not heard this term, but I've certainly seen it (and been guilty of it myself). Making a change requires touching a handful of different classes instead of just one or two.
• God class: I actually have heard of this, and if you consider classes with 300+ line Page_Load methods in ASP.NET to be God classes, then I've certainly seen it and done it.

The metrics that she uses to find these smells are not traditional metrics, but "concern-driven" metrics, meant to identify code "scattering" and "tangling" (i.e. the code that AOP is meant to help refactor), and includes:

• Concern Diffusion over Class (CDC)
• Concern Diffusion over Operation (CDO)
• Number Concerns per Class (NCC)
• Concern Diffusion over Lines of Code (CDLOC)

These metrics weren't defined in the slides, but I found them in another white paper from Columbia.

Continued my series of posts designed to cut through the sometimes obtuse terminology around AOP, this week I'll be defining "cross cutting concerns". Well, it's the title of the blog, so I guess I should explain it at some point, eh?

A cross-cutting concern is perhaps the "softest" of the terms, because it's more of an architectural concept than a technical one.

Basically, a cross-cutting concern is some piece of functionality that may not neatly fit in to normal object-oriented architecture, and most likely doesn't add business value or satisfy a requirement on its own (aka non-functional requirements). Logging is the most common example of a cross-cutting concern, because you might use logging in the UI layer, in the business logic, in the persistence layer, etc. Even in an individual layer, logging could be used across all classes/services, cutting through and crossing all the normal boundaries.

Other examples of cross-cutting concerns, which should come as no surprise if you're a regular reader: transactions, exception handling, INotifyPropertyChanged, authorization, caching, multi-threaded/asynchronous programming, auditing (very similar to logging). What else?

Sorry for another slow week of posts--I've been busy on a couple of side projects (neither of which involve AOP), so my evening writing time has been cut a little short. Here's your weekly dose of AOP links:

• White paper on using AOP for remote usability testing (PDF). I think this is the second white paper I've seen on using AOP for something like that. It's an interesting idea that needs some exploring...
• Reminder that Chad England is still posting in his series on PostSharp. Here's part 2 and part 3.
• I've used AOP to make threading/async coding more declarative and easier to read. Jonathan George did a blog post on a "fire and forget" asynchronous aspect.
• For you Game of Life enthusiasts, here's a github blog post from Reginald Braithwaite about using AOP to perform garbage collection in the game of life.

That's it for this week--keep sending in those links for next time.