Tuesday, August 25, 2009

Aspect Oriented Programming

This is a two part article, first part concerns Aspect Oriented Programming, second part will give a brief tutorial of an aspect library.

Since the dawn of computing men have been drawn to the challenge of making software programs to utilize expensive computing resources efficiently with minimum rework, in a minimum amount of time.

There's been a continuous evolution in the programming languages, with various languages becoming extinct. First there was the machine language, 1 and 0, then assembly, programming in low level opcodes. Assembly languages though made the things a little easier, but did not do enough for increasing readability and maintainability.

Then came higher level procedural languages, where all the programs were written in sequence without much division of work and context. Everything was in one humongous piece of code. If something went wrong or a new resource become part of the project its was a hell to maintain and communicate.

But as the computing resources became less expensive and more powerful, resulting in software programs to be more complex and increasing in size, a paradigm shift was needed.

To elaborate consider, software is like Clay: it is soft and malleable early in its lifetime, but eventually it hardens and becomes brittle. At that point, it is possible to add new bumps to it, but its fundamental shape is fixed, and it can no longer adapt adequately to the constant evolutionary pressures of our ever- changing world. So you have to be right from the start and structure should be such that whole tower of code should not toppled over when you enter a new block of code.

Modularity was needed to divide code according to the work assigned to it or the context, abstraction was needed so that changing implementation of one module, you don't have to change all of the code. Code reuse was needed instead reinventing the wheel every time.

The answer was object oriented programming. To model programs in classes and objects, and function being the result of relationship between those classes and objects. It made a lot of things easier, introduced modularity, encapsulation, reuse ability and to conclude reliability.

Though once revolutionary, object oriented programming has reached a certain stage where the cracks have begin to appear. Several scenarios have come to surface where object modeling is not sufficient. Many requirement do not neatly decompose in to behaviors centered on a single focus.

Lets take example of org.apache.tomcat, an open source project. XML parsing may be neatly modularized in to one, class. Same is the case with URL parsing it may be used in two classes, through inheritance, but all the necessary functions can not be modularized so neatly.

Consider the case of logging. Almost all the modules of Tomcat needs to write one thing or the other in log. Where should logging implemented ? Same is the case with session expiration, we will need to use it for the application Session, server session, Standard Manager, Standard Session Manager,and many other classes.

We end up in tangled code, same fragment of code is divided in many places. The code is difficult to reason about, difficult to change owing to its non explicit structure. The big picture of the code is not clear. If we have to change the abstraction we will have to change the code using that abstraction too. This is called crosscutting concern. The concern that is not limited to one or two classes only but is spread all around the code base. We have to make sure that no inconsistent changes are being made, and not to break it accidentally.

Well the AOP idea is that:

    • Crosscutting is inherent in complex systems.

    • Crosscutting concerns are critical, they have a natural structure and a purpose.

So lets manage crosscutting concerns in a well modularized way, with linguistic and tool support through out the life cycle. Aspects are crosscutting concerns. Object aspects are those that are common to many objects, and can not be modularized, abstracted or contained in a single class.

Aspect oriented programming provides us a way to use the principles of Object orientation for crosscutting concerns

The main issue would be adoption of aspects and aspect oriented programming, a step by step approach is suggested below:

  1. Develop support for existing code, perform performance measurement to gage efficiency gains by using aspects.

  2. Develop error handling standard and the contract with method for aspects, also a way to monitor aspects.

  3. Integrate aspects in to modular design, also make them persistent and secure

  4. make whole aspect libraries, we are at this stage with respect to aspect4j.

  5. Finally try to fit aspects in to larger picture by integrating with other product line like web development mobile development etc.

There are distinct expected benefits for each evolutionary step

  • Add aspects to existing code

      • Untangle axillary concerns for improved abstraction and modularization.

      • Improve quality resulting in less backtracking and error resolving.

      • Reduce code size due to less redundancy in the code.

      • simplify problem solving- if the need arise debugging would be easier instead of getting lost in a jumble of code.

  • restructure whole code for aspects

      • Easy to add aspects.

      • Efficient code from the start.

      • Improved code agility.

  • Aspect oriented architecture

      • Aspect reuse would be possible

      • Aspect extensibility


Resulting in architectural qualify and flexibility of code

AOP GOOD; AOP BAD; AOP GOOD; AOP BAD ???

When are aspects appropriate:

  • Is there a concern that crosscuts across several objects and classes??

  • More importantly is it beneficial to separate that concern ?? beneficial by increasing clarity, reducing tangling and making it easy to modify and extend the code.

  • Captures the story well.

  • Lead to good implementations measured by code size, tangling coupling.

  • Good modularity even in the presence of crosscutting concerns, resulting in good reputability, maintainability and evolution.

So here now you have the introduction to aspect oriented programing, next I'll shed light on the aspect J a Java library for programming in aspect oriented languages.

No comments:

Post a Comment