Application Areas of Aspect Oriented Programming

Yalçın Sertkaya, Software Consultant, Aug. 11, 2009

Aspect Oriented Programming (AOP) is a programming paradigm that, other than its main purpose “increasing modularity”, finds many usage areas nowadays. This blog is intended to give an introduction to Aspect Oriented Programming (AOP) and to highlight its not widely known usage areas.

Before Aspect Oriented Programming (AOP), we will define two modularization problems named “Tangled” and “Scattered” codes:

An implementation is called “scattered” if its code is spread out over multiple modules. A code is “tangled” if it includes any logic other than its principal one. Both are big design problems in terms of modularity.

At first sight, it looks simple to refactor these types of problems by decomposition methods like separating or combining them in classes (or procedures for structural languages). Of course, these methods can help to solve them, but these types of problems generally are indicators of crosscutting concerns, and in such cases, they can’t be refactored using decomposition methods. We will define crosscutting concerns further in detail, let’s give a simple and classic example for now:

An example about debiting a customer account, which includes only debit business logic, is given below:

Code Sample
figure 1

If the following are also needed, as an enterprise development policy,

After adding these concerns to the debit logic, the final code will look like this:

Code Sample
figure 2

Now, we have an entry level tangled code example. All logic, other than debit business logic, will be defined as crosscutting concerns.

Wikipedia’s more formal definition of Cross-cutting is:

Cross-cutting concerns are aspects of a program which affects (crosscut) other concerns.

For other methods of financial class we will also find similar tangled codes (see below figure). Conversely, logging, authorization and audit modules will have symptoms of scattered codes. The below figure also shows where its name “cross cutting” came from.

Cross Cutting

Below are listed, examples of issues, other than logging and/or authorization and which require exception handling;

  etc.

Some cross cutting concerns can be reduced by a framework infrastructure. Such framework makes some cross cutting concerns clear to the developers. For example, an enterprise bean with a container managed transaction attribute has nothing to do with transaction consistency so its code will not include any transaction management logic.

Software framework that is used for CoreFinans, banking product of IBTECH, handles many of the crosscutting concerns, by its underlying infrastructure. The framework was developed in IBTECH and it uses Service Oriented Architecture by reflection. So transactional, database connection pooling, logging, exception handling, security, etc. related cross cutting concerns are handled clearly to the developer at the SOA layer. As a result, developers focus on only business logic without any concern about other types of complex system logic and they produce readable, modular, reusable code.

For many years, the search for cross cutting concern solutions, have kept software researchers busy. Cross cutting concern problems are also defined as the tyranny of the dominant decomposition. (by IBM T.J. Watson Research center). In fact, before 2000, some very good solutions, like composition filters and Hyper/J, were found, but none of them had a wide usage comparable to Aspectj released at 2001 by Xerox.

AspectJ

Aspectj (as well as Aspect Oriented programming) relies on separating crosscutting concerns from the code. Aspectj encapsulate concerns inside “aspects” by seperating them from the original code. It is possible to develop a code as in figure 1. After applying Aspect Oriented Programming (AOP), the above example will look as follows (figure 4):

AspectJ
figure 4

Aspect Programming Implementation

AspectJ implementation results in 4 new concepts:

The general form can be summarized as

If {point cut matches} then apply {advice}

A more complete usage can be seen at the AspectJ web page: http://www.eclipse.org/aspectj/doc/next/progguide/starting-aspectj.html

Aspects are developed separately and then are joined to the raw code by a weaving process at the compile time or execution time according to the implementation.

Usage Areas

Aspect Oriented Programming (AOP) is used for some purposes other than crosscutting concerns.

The other Side of the Coin

Although there are many application areas for Aspect Oriented Programming (AOP), it must be used carefully because it has many potential problem sources. For example if a programmer makes a mistake while defining point cuts, it may cause errors for a wide range of programs. Conversely, a programmer can change some attributes of a program that is used as a pointcut from an aspect, this time the aspect will not be executed for changing programs. As a solution for these types of problem, AspectJ Eclipse Plug-in (AJDT) enables the developers to investigate which aspect matches which methods.

Conclusion

Although it seems that Aspect Oriented Programming (AOP) has become more popular lately, Google Trends don’t say similar things. Graph shows the Google search rates for the time scale from 2004 to date, and it shows a big decrease. Anyway, Aspect Oriented Programming (AOP) provides great help regarding modularization and many different software areas, and it doesn’t look like its usage will ever end.

Search Volume index
figure 5