Aspect Oriented Programming (AOP)

AOP has recently emerged as a programming paradigm that, many believe, will become main-stream in near future. It is indeed an interesting approach to designing systems. There are numerous tutorials on this subject available on the internet, but most of them primarily focus on the usage of specific frameworks/aspect-oriented-languages. There is not much coverage of AOP as a programming paradigm from historical perspective, so I thought I would attempt to write one and contribute to AOP in my small way.

This blog entry is not intended to be a tutorial on AOP and it does not cover any AOP framework or language in great detail. It aims to examine the evolution of AOP and tries to understand where it might go from here.

What is AOP: AOP is a way of programming where one:
1) Identifies pieces of code addressing a specific concern/aspect that are scattered throughout the system.
2) Extracts those pieces of code and moves them to one central place called Aspect.
3) Repeats this process for different concerns (transaction, security, caching, object pooling, logging, remoteness, replication etc.) creating one aspect per concern.

For example, in a typical object-oriented database application there is likely to be transaction code scattered throughout the system. You can use AOP to extract all transaction handling code and move it to an Aspect.

Aspect is to AOP what Class is to OOP: Think of Aspect as a container of code pertaining to a specific concern.

AOP Languages and Frameworks: You can use AOP in your projects by using an AOP framework or by using an AOP language:
1) AOP languages, such as AspectJ, add language constructs (e.g. Aspect) to existing languages. For example, AspectJ adds some language constructs to Java to support AOP. In other words, AspectJ is a superset of Java, or AspectJ is to Java what C++ is to C.
2) AOP frameworks do not add any language constructs to existing languages. They use configuration files, mostly XML, to define aspect related information. Examples of this approach are JBossAOP, Spring, AspectWorkz, Nanning, DynaAOP etc.

As you can see there are many more AOP frameworks than AOP languages:
1) It is less difficult to create a framework than it is to enhance a language.
2) AOP languages can be hard to work with without proper IDE support.


Some examples of AOP:
todo


Code Readability: In AOP programs, there is more to code than meets the eye. Consider the following line of code:

Student.addCourse(course);

In Java, based on this line of code, it is easy to determine what the next line of execution would be. It is the addCourse method of Student class.

In AOP, it is not so easy to determine what the next line of execution would be. It is possible that addCourse method is intercepted by an Aspect.

Presence of aspects in AOP makes it harder to understand code.

But with good tools support this problem could be mitigated. For example, eclipse has good support for AspectJ and it highlights lines of code affected by aspects.

Picture/todo


AOP use and AOP abuse: Identifying and extracting independent concerns into separate aspects is easier said than done. Except for some well understood system concerns like transactions, security, pooling etc. it is hard to apply AOP to divide a system into a set of aspects each handling an independent concern.

1) IMHO, system level concerns would be aspectized by specialists and would be made available as frameworks to application programmers. In other words, most usages of AOP would be by framework developers and not by application programmers. Spring/JBoss appear to be moving in that direction.

2) Some applications would need aspects not handled by available frameworks but IMHO they would be exceptions rather than the norm.

3) Most common usage of aspects by application developers would be for logging, system monitoring etc.

4) For pure business logic code, AOP usage would be extremely rare. It is hard, though possible in rare scenarios, to aspectized business logic code.

AOP in historical perspective: If we look at the history of programming languages, one clear trend is that of increasingly greater expressibility. Newer programming languages allow us to express more and more complex ideas allowing us to solve increasingly difficult problems in shorter timeframes. AOP is certainly a move in that direction. It attempts to divide software into a variety of aspects so that each aspect could be developed by specialists, leading to higher quality software. How much aspectization could be achieved remains to be seen.

EJB (more generally, IoC containers) is conceptually similar to AOP. They take the business logic code provided by application developers and effectively add a wrapper around it to provide remoteness, failover, transaction, security, pooling, caching etc. It is interesting to note that JBoss’s implementation of EJB is based on interceptors using Dynamic Proxy of Java. Interceptors using dynamic proxy is now the foundation of quite a few AOP frameworks in Java, most notably Spring, Nannning and DynaAOP.

Also interestingly, in our own team, Brent used interceptors using dynamic proxy to support transactions in at least one project.

It is important to point out that not all AOP frameworks are based on interceptors, though conceptually they all behave in that manner. Many AOP frameworks, for example JBossAOP and AspectWorkz, modify application classes at runtime to insert aspect code (this process is called aspect weaving). Other AOP frameworks, for example AspectJ, perform aspect weaving at compile time.

It is clear that, conceptually, aspectization of software, in order to enable development of system concerns by specialists, has been going on for a long time. What AOP movement has done is, it has formalized this kind of software modularization by identifying recurring concepts like aspect, advice, point-cut, join-point etc. and thus formalizing a new programming paradigm. This new paradigm has lead to a competitive world of AOP frameworks and languages that only focus on perfecting an extremely generic infrastructure to enable software modularization in terms of aspects.

FAQ:
(1) Is AOP going to replace OOP?
No, AOP complements OOP.
(2) Does AOP degrade performance?
In theory, yes because of extra calls added by interception, but in most cases there would not be a perceptible degradation.