AOP’s goals

The main aims of AOP are to improve program modularity by increasing the “separation of concerns”. What exactly does that mean? To be certain, plain old Object-Oriented Programming (OOP) already drastically increases program modularity; but there is still room for improvement. In particular, AOP seeks to address the issue of crosscutting concerns, that is, functionality which “cuts across” or overlaps multiple areas of a system.

For example, most web applications will have authentication and/or authorization as cross-cutting concerns. Some pseudo-code for showing a user’s personal “Todo” list is shown below:

if (isUserAuthenticated())
{
  items = getUserTodoList(getUserContext());
  foreach (items as item)
  {
    // Output each todo item to the page...
  }
}
else
{
  // Redirect to login page...
}

The act of checking if the user is authenticated has become entangled with the core business logic of showing the items of the “Todo” list. Indeed, this can become cumbersome as the business logic functionality expands; for example, we might have to write such “boilerplate” code to check for authentication for each page that requires it.

Of course, this is just a contrived example. This particular authentication problem has already been nicely solved in many languages such as Java (J2EE) and PHP. In either of these languages, for instance, you’ll find multiple frameworks that take the grunt work out of a common problem like this, but it highlights how cross-cutting concerns can interfere with and decrease the modularity of a system, making it harder to maintain.

Separation of concerns aims to refactor this code to reduce the overlap in functionality, so that core business logic can be separated from the cross-cutting concerns, which then become known as aspects. One area that AOP suffers from is the confusing terminology. Thankfully, the folks behind the great Spring Framework have written an excellent guide to the terms and AOP itself. I suggest you take at least a quick look at it.

Simplicity through Separation

AOP achieves its goals by defining join points where certain advice can be executed before or after the code at the join point. A join point is simply a certain point in the program code and is typically the point where a method begins execution.

Typically, there are three types of “advice” that can be weaved or attached to a join point: Before, After and Around. “Before” advice will execute just prior to the method to which it is attached, but cannot modify the execution of that method. That is, the “Before” advice cannot stop the execution of the method. “After” advice will execute directly proceeding the return from the method to which it is attached, and it can typically get access to the return value from the method.

“Around” advice is called before the method itself, and can alter the behaviour of the method to which it is attached. Typically, this includes deciding whether or not the method should be invoked at all, or even modifying the arguments passed to it. Thus “Around” advice is the most powerful.

It should be noted that for AOP to be truly effective the invocation of the advice attached to a method/join point must be transparent. That is, once the advice has been attached to a target object/method, one should not have to invoke the target method in any special manner in order to get the advice to fire.

One other term to note is the pointcut. A pointcut is simply a predicate/expression that selects a set of join points. Thus, by defining a pointcut, advice can be attached to multiple join points that meet/match the pointcut’s expression. In fact, this is typically how AOP is modeled from a high-level point-of-view. When reaching a join point that matches a certain pointcut predicate, the advice associated with that pointcut is invoked.

AOP with jQuery

But all of these explanations and terms may still be confusing without a concrete example, so for that we’ll take a look at the jQuery AOP plugin. JavaScript (especially with jQuery) is not really a place where AOP is used heavily or needed, since the use of callbacks already provides some level of separation of concerns. Indeed, the Ajax Events available for hooking into using jQuery already provide some sort of AOP-like functionality.

Having said that, the jQuery AOP plugin is quite easy to use. Here’s a quick example that allows you to keep track of the number of event handlers invoked:

Site = new Object();
Site.handlerInvokeCount = 0;
jQuery(function()
{
  // Note: Must apply the advice to the function(s) BEFORE binding as an event
  // handler.
  jQuery.aop.around( {target: window, method: /^handle[A-Z]/},
  function(invocation) {
    window.alert("Invoking `"  + invocation.method + "`");

    window.alert("Number of event handlers invoked so far: " + ++Site.handlerInvokeCount);

    // Note: Can stop the invocation of the target method by *not* calling
    // proceed().
    return invocation.proceed();
  });

  jQuery("form").submit(handleFormSubmission);

});

function handleFormSubmission(e)
{
  e.preventDefault();
  window.alert("Inside handleFormSubmission");
}

Here, we attach advice around any global function whose name starts with “handle” and is followed by a camel-case name, such as handleFormSubmission. We don’t do anything interesting but increment and report the current count for the number of “handle” methods invoked. We then attach the handleFormSubmission to a form submission event.

It’s worthwhile to note that you must attach or “weave” the aspect to the function before binding the function any any events. This is because when you bind a function to an event, it is copied over by reference. The jQuery AOP plugin essentially weaves advice to functions by creating a new function that includes both the advice and an invocation of the original function. However, if you do this after binding the function to an event handler, the event handler will still refer to the original function, that is, the one without any advice attached to it!

Conclusion

AOP may have limited utility in JavaScript, as I’ve found, thanks to excellent JavaScript libraries such as jQuery. jQuery already achieves decent separation of concerns thanks to the many built-in callbacks, mainly for Ajax events. It also supports the use of custom events, which may be used in a similar manner to some AOP advice types.

While a full-fledged AOP solution may not be needed in some situations, it’s worthwhile to note that many frameworks still adopt an AOP-like model. For example, CakePHP’s controllers have an extensive list of callbacks that can be used to control execution of the main controller’s actions. These allow you to separate out your concerns from the main program logic for maintainability and reuse.

After discovering that Rock Band for Wii turned out to be a disappointment, I recently decided to sell it off and save up for a Playstation 3, which I bought last week. I also picked up a copy of Rock Band for PS3 and am now playing Rock Band the way it was meant to be played: With downloadable content (DLC), properly-rendered gameplay and character creation. (I actually bought a used copy of just the game and then forked over $100 for the PS2 special edition, taking advantage of the current promotion and saving about $40 after taxes)

Does this mean I’ve lost faith in the Wii? Well, probably not. My disappointment in Rock Band for Wii was not entirely Nintendo’s fault, even if they have acknowledged storage/space issues, since many have pointed out that Harmonix may have cut a few corners by simply porting the PS2 version over to Wii, saving time but perhaps selling short its full capabilities. This point is further underscored by the fact that the upcoming Guitar Hero IV: World Tour, will feature DLC in the Wii version – though perhaps we’ll see if that’s the case when it arrives later this year.

I think a better way to put it is that the Wii and PS3 occupy different segments with only partial overlap. The Wii has a lot of fun games, but at times the graphical limitations can be annoying; one simply can’t rely on unique game play for everything.

On the other hand, the PS3 is all about power and features: This thing is very much like a computer in terms of its utility, and I’m very impressed by what’s offered. However, there are many games on PS3 that just don’t appeal to me, despite their graphical superiority. Conversely, the fact that it’s so much like a computer can also be a detriment. When I’m playing on a console, I don’t want to have to think about things like HDD space and so forth – I just want to game. However, HDD space seems to be an issue, even with the 40GB PS3. I only have two games “installed” – Rock Band and GTA IV, and I’m already using up 10 of the 37 GB available. Perhaps this is because GTA IV is a space hog, but nevertheless I’m looking to upgrade to a bigger HDD once I can snag a deal.

You know the feeling – you arrive home from school or work to find a slip posted on your door advising you that an attempted delivery of your package failed. The slip will often also say that one or two more attempts will be made, but barring that, you’ll have to make a trip to a shipping depot that’s usually located in the middle of no where to obtain your goods.

I’m willing to bet that 90% of adults aren’t home between the hours of 9 AM – 5 PM, the time that deliveries usually occur at. So, why do most shipping companies only delivery parcels at these times? I understand that likely a majority of their shipments are to business addresses, making the current operating hours suffice for those situations, but certainly a significant number of packages are addressed to homes as well. While online shopping has slowed in recent times, it still accounts for $116 billion (USD) in the United States alone, and all that merchandise has to be shipped.

After hours shipping

So, why not offer “after-hours” shipping for the majority of consumers who are working during the day? After all, there are many other services, such as banking, that are starting to be offered into the evening when they’re more accessible to the general population. While this would undoubtedly cause some hassles with shipping companies, they’d save trouble in some respects, as there would be less missed deliveries and fewer repeated attempts. Additionally, when ordering items, one should be able to indicate whether day or evening service is desired – this would effectively help separate shipments into “business hours” and “after hours” categories.

It’s not all bad

What prompted me to think about this are a few recent experiences I had with local delivery companies. When I ordered furniture from IKEA for my new apartment, they used a local delivery service to ship the items to me. Thinking there was no way I’d be able to catch them, I let the superintendent of my building know about the shipment so that he would let them in on my behalf. Surprisingly, the delivery man called me and left a message on my answering machine asking what time would be best for me. Thankfully, after 6 PM worked for both of us. Maybe this is standard practice for furniture deliveries, but it was still nice not to have that hassle.

I also recently ordered a keyboard tray for my new desk from Office Depot. I hate having the keyboard on the same surface as everything else, and the new desk I got from IKEA didn’t have a keyboard tray. Shipping was free for the item, and again, the local delivery company (a different one from before) had the courtesy to call me before dropping off the item. As before, I was able to schedule an after-hours drop off time.

Perhaps I’m just biased because I don’t yet have a car and going to out-of-the-way shipping depots is a lot of trouble for me. However, judging from the amount of people I saw picking up items at the Purolator shipping depot the last time I was there, I think the service would be warranted.