Aspect-oriented logging and SmartInspect

One of the things that bugs me a bit when adding logging code to applications is that they make the actual code harder to read. Each line of logging code competes with a real line of application code. You have to find a good trade-off between readability, logging performance and log coverage and that’s not easy to do in every case. Ideally, your entire application is well-instrumented and you can switch logging on or off for certain application modules depending on your needs. But this usually results in hundreds or thousands of additional lines of code, just for logging. Of course, the benefits from having all those log statements in place far outweighs the disadvantages of the code inflation, but still, those lines are anything but beautiful.

Another issue with logging is that adding all those log calls takes time and getting a good log coverage can get tedious when instrumenting a large existing application. That’s not necessarily the case if you add logging from the very beginning of development, but let’s face it, most applications have already reached a mature state before you think of adding diagnostics and logging features. Adding such features often comes as an afterthought (which it shouldn’t, ideally), so when you or a customer experience a problem which you cannot easily reproduce, you are instrumenting your application or parts of it and that isn’t any fun at all. We usually recommend instrumenting the most important parts of an application first and then building from there, but it’s still, well, time-consuming.

Fortunately, there are approaches and techniques to solve both of these problems, with one of the most promising being aspect-oriented programming (or AOP for short):

“Aspect-oriented programming (AOP) is a programming paradigm that increases modularity by enabling improved separation of concerns. This entails breaking down a program into distinct parts (so-called concerns, cohesive areas of functionality). All programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g. procedures, modules, classes, methods) that can be used to implement, abstract and compose these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they “cut across” multiple abstractions in a program.”

It’s been several years since I first heard about AOP. Back then, AOP was being marketed as one of the next big things in programming (okay, it’s been several, several years now). Supporters of AOP claimed it would change programming and software development as much as object-oriented programming did 20 years ago. We now know that it hasn’t and probably never will to that extend, but it’s for sure a nice addition to the developer’s toolbox.

So, what’s so special about AOP? The most beautiful aspect of AOP is that it improves the modularity of your application by putting parts that logically belong together in one central location. You can implement security concepts, caching, transactions, design by contract and of course a complete logging solution without touching any of your existing classes or methods. This means there’s no need for repeated boiler plate code for checking method arguments for null values, no repetitions of the same begin/commit/rollback transaction code or for adding exception logging code to every exception handler. You simply tell the AOP framework which parts of your application should make use of which features (also called aspects in AOP terminology) and the AOP framework does all the work wiring those aspects to your application modules.

In the coming months, we will take a look at some of the available AOP frameworks for the different platforms supported by SmartInspect here on this blog and show how to build a sophisticated logging layer with these frameworks and our own logging tool SmartInspect. Stay tuned!

Articles published so far: