Aspect-Oriented Programming

Author: Mikael Jansson
Date: 2006-02-23

Presenting at Chalmers, Sweden, a paper by:

Gregor Kiczales, John Lamping, Anurag Mendhakar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier and John Irwin

Xerox Palo Alto Research Center, 1997

Why AOP?

Have you ever felt that you write the same code over and over again, but you can't really parametrize on the parameters of the problem?

If you run into a case where...

...there will be aspects!

Case Study: Image Processing

Putting images through a list of filters:

Easily composable, just apply the next filter on the result of the current filter!

Case Study: Image Processing

What about efficiency?

Not feasible!

Aspects vs Components

Observation: Systems are generally built using two constructs

Component Language

Image processing revisited

Aspect Language

Rewriting filters -- the weaver

To working code

Image processing system developed at Xerox. Goals: memory efficiency and code maintainability.

Results: better space efficiency and worse time efficiency, but with 10 times less code!

(additionally, the paper includes an example using Java)

Why aspects?

Measuring efficiency:

reduction in bloat due to tangling =
(tangled code size - component program size) /
sum of aspect program sizes

As such, anything greater than 1 is a success. Putting the the image processing system in concrete figures, we get:

(35000-756) / 352 = 98

Aspect Orientation

Writing a system requires three parts:

Expose joint points in the component language for the weaver to, well, weave in the aspects.

Open Issues

As of writing (1997), not much real evidence of aspects being generally applicable.

Summing Up

If you're writing code doing a similar task for a heterogenous set of components and behaviours, consider introducing aspects to your system!

EOF.