CSC/ECE 517 Fall 2009/wiki2 9 km

Aspect-Oriented Programming

AOP is a programming paradigm in which the model can be dynamically modified to pefectly satisfy the growing/new requirements of a system. It complements object oriented programming by allowing the separation of cross-cutting concerns, thus modularizing them. AOP allows the developer to dynamically modify the static object oriented model to create a system that can grow and adapt to new requirements and expectations. So basically AOP is all about managing the common functionalities which span across the whole application (hence the term cross-cutting) so that it is not embedded within the business logic. It's very helpful in development of applications which change drastically during their lifecycle.

Few examples of where we can make use of AOP are:

• logging
• managing security
• transaction management

We can easily see here that these concerns are cross-cutting, meaning that they are used 'horizontally' across various points in the system. Example:

Why AOP ?

To the uninitiated, AOP may seem to be something which can easily be done by Object Oriented Programming ! Infact this is true to some extent. Everything that can be done using AOP can also be done without it by just adding more code. A simple example of how AOP works is as follows: Assume you have a graphical class with many "set...()" methods. After each set method, the data of the graphics changed, thus the graphics changed and thus the graphics need to be updated on screen. Assume that to repaint the graphics you must call "Display.update()". The classical approach towards this would be to add more code. At the end of each set method you would write void set...(...) {

   :
   :
   Display.update();

}

Now, if we have a few set() methods then we are fine and we can do this easily. But what if we have a huge system, and say we have hundreds of set() methods ! Two problems arising here are: 1) We would have to add the line Display.update(); in all these places 2) We would have to remember to add this line to any new set() methods that we create. If we forget, we just introduced a bug ! With AOP, we can shunt the responsibilty of 'remembering' to 'update the display' [executing Display.update();] whenever set() function is executed by writing an aspect

after() : set() {

  Display.update();

}

So instead of writing the update code yourself, you just tell the system that after a set() pointcut has been reached, it must run this code and it will run this code. No need to update 200 methods, no need to make sure you don't forget to add this code on a new set-method. Additionally, we also need to write a pointcut:

pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);

which basically means that if a method is named "set*" (* means any name might follow after set), regardless of what the method returns (first asterisk) or what parameters it takes (third asterisk) and it is a method of MyGraphicsClass and this class is part of the package "com.company.*", then this is a set() pointcut. And our first code says "after running any method that is a set pointcut, run the following code".