Aspect oriented programming (part 1)

When writing software there is a separation between the domain of problem you are trying to solve and the enterprise plumbing needed to make it stable, secure, and robust.  However, although the separation of those two domains is logical, that plumbing code generally has to live inside of the same space as the domain code to be effective.  For instance, how many times have you been through a system and seen logging statements littered throughout a model?  Or when utilizing a design pattern see very similar calls to provide for features like lazy loading or chains of responsibility?  This ultimately creates confusion between the two spaces, increases the amount of code you need to write and makes things more difficult to manage.  So what do you do?

While there are in fact a variety of ways to go about solving that problem, Aspect Oriented Programming (AOP) has an unique answer to the above problem.  Aspect oriented development is centered around the idea of modular pieces of code which can be applied to existing code to address those cross cutting concerns.  A concern, in this context, is a focused subset of functionality such as logging.  Logging is an enterprise need that is applied all over the domain and yet really is focused and concerned with a relatively simple task (i.e, declaring that something happened).  I don’t however, want to give the impression that the scope needs to be as large as the entire domain.  AOP is simply the idea of code injection as a means to address a problem.  The scope in which that is done is usually as large as the concern you are trying to address.  Logging is large, ergo the scope is large.  In some cases your concern might only be for a specific class, but by using an aspect you create a reusable piece of logic for later.

The goal here is to abstract away from the domain the concern.  Within the context of AOP, how we would generally go about doing that is to move the logging code to it’s own unique place (an aspect).  By encapsulating away the functionality of logging, we could then apply it to the needed functions.  Different aspect frameworks go about this slightly different.  In the world of buzzword bingo we would call this a join point.  That is, how does the aspect framework know WHERE in the assembly to apply an aspect.  In some frameworks this is accomplished through language extensions (AspectJ).  In others it’s done through XML (Policy Injection Block & nHibernate).  The one that I am fond of is attribute based.  By taking an attribute and applying it to either a class, a method, or even an assembly, I can tell my aspect framework what I am trying to do (declarative programming).

That only gets us part of the way.  Once you tell the framework where in the code you need to apply the aspect, you still have to tell it HOW you need it applied.  In most aspect frameworks you are allowed to intercept a call to those needed functions before, after, and both before and after the call is made to them.  Some frameworks also let you intercept the exceptions thrown by functions.  Deviating from the norm, there are even aspect frameworks that let you modify access to things things like private fields on the class, or even the constructor itself.  That is, however, limited to particular frameworks and not always available.

Though I hinted at some of the underpinnings of AOP, the implementation piece of it is relatively hairy.  There are generally two types of aspect frameworks, proxy based and code injection.  Proxy based is among the most popular, but MSIL has it’s place in the aspect framework world.  I will talk about those more and their implications in my next post.

In summary, the goal here is to reduce the amount of code you write, get your product on line as quickly as appropriate and ultimately produce better and cleaner code.   Less is more.

Save lots of money by switching to aspects.

*queue cheezy geiko music*

Post a comment or leave a trackback: Trackback URL.


  • Joshua T. Rowe  On June 15, 2009 at 4:40 pm

    Logging is a great example to introduce the idea, but I think in practical terms it is more maintainable to have the logging inside the code being logged. A good practical use of AOP that I have seen is transaction management inside the Spring Framework for Java. It’s configured via XML and all of the mojo is presumable implemented with AspectJ.

    I think that AOP can be really powerful, but it’s not something that you want every programmer dealing with. But it’s a great tool for frameworks, because you can provide complex runtime configurability without writing tons of code. And so junior programmers don’t have to deal with aspects.

    Also I don’t think the term ‘join point’ is buzzword bingo. I think that it is a legitimate term used to describe a specific technical concept.

    Could you post a code example of attribute based join points? I think I have an idea what you mean, but I’d much rather see code. 🙂

    • pinvoke  On June 16, 2009 at 12:12 am

      I think it ultimately depends on what type of logging and how your architecture is implemented. Some logging I can see inside of a specific class, but for lots of generic logging calls I think that Aspects provide a much more maintainable solution. Remember, the idea here is cross cutting. If there are scenarios that don’t apply to that, then you shouldn’t use aspects.

      My next post will have some samples with code, including attribute based.

  • S Kotrappa  On June 16, 2009 at 1:43 am

    I do understand that understanding AOP aspects and using it in application development is difficult for junior programmers.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: