point
The Smart Techie was renamed Siliconindia India Edition starting Feb 2012 to continue the nearly two decade track record of excellence of our US edition.

Aspect-oriented Programming demystified

Bhaskar Chavali
Friday, November 30, 2007
Bhaskar Chavali
Aspect-oriented programming (AOP) has recently become quite a hot topic. The name, which sounds similar to object-oriented programming (OOP), may convey the impression that AOP is an alternative to OOP. But despite the similarity in name, AOP is not expected to replace OOP and in most cases it supplements an OO programming language and provides the architect with techniques to come up with elegant solutions to some of the programming challenges not easily handled through object-orientation. This article will explain the basic AOP concepts and touch upon the advantages and limitations of using AOP.

In the ever-changing technology world, designing an application, which is both maintainable and extendable, is always a big challenge. In the process of creating the architecture for such an application, an architect considers not only the present requirement but also has to take into account possible future requirements. However, it is not possible to predict the future. An unforeseen requirement can lead to a significant change and re-implementation of many parts of the system. The alternative of focusing too much on low-probability requirements can lead to a confusing and bloated application. For example, if the current system does not require logging, should the architect include a logging mechanism in a system?

Therefore, the system architect always faces the dilemma of whether to leave out the feature and under-design or to consider it and over-design. The question of how much design is too much needs to be answered. The task of the architect of a reusable library is even more difficult because it is harder to imagine all the usage scenarios for the library. In a real life situation, there will always be requirements, which have not been foreseen at the time of initial design. Some of the changes may be non-functional in nature and may cut across many programs. The need to optimize performance can also add to the problem. A design would have been made initially to address a single function, but over a period of time it tends to lose its purity. Additional functionalities are added to the object. In AOP terms, the problem is known as ‘mixing of concern’ and AOP is designed to avoid this problem. It addresses these issues and solves them in a more elegant way.

This mixing of concerns leads to a condition called ‘code scattering’ and ‘code tangling’. With code scattering, the code necessary to fulfill one concern is spread over the classes, which are designed to fulfill another concern. Code tangling involves using a single method or class to implement multiple concerns. Both of these problems break the fundamentals of OO and cause headaches for designers. A developer doesn’t have to be in the industry long to find out the effects of tangled and scattered codes that include classes that are difficult to change, codes that can’t be reused, and codes that are impossible to trace.

Like many innovations in the field of IT, the origin of AOP also goes back to Xerox PARC. Gregor Kiczales and his team originated the concept of AOP in 1996. His team also developed the first and most popular general-purpose AOP language, AspectJ, which was an extension of Java. Then it was a new approach for designing programs. It was also a set of guidelines to make more readable and reusable code.
The basic principle of object-oriented programming is to group functionality into classes and create relationships between these classes. However, in practice it is not always possible to group a single functionality into one class and the functionality may be spread over more than one class. In AOP terms, such functionality is referred to as ‘aspects’ or ‘concerns’. In a credit card processing system the primary functional requirement would be to process payments, which is the ‘core concern’. However, there will be other non-functional requirements like logging, transaction integrity, authentication, security, performance, and so on, and these are ‘crosscutting concerns’.

Share on Twitter
Share on LinkedIn
Share on facebook