Copyright © 2004 Gene Michael Stover. All rights reserved. Permission to copy, store, & view this document unmodified & in its entirety is granted.
These are my own notes about Aspect Oriented Programming. It would be equally accurate to say ``These are disorganized & not nearly authoritative notes & references about Aspect Oriented Programming''.
By the way, don't assume that the existence of these notes indicates I think Aspect Oriented Programming is great, good, useful, or destined to be the next big thing in software development.1 I just wanted to figure out what it's about, how I might use it, or what ideas I might take from it even if Aspect Oriented Programming as a whole is not very useful.
I'm most interested in how to implement AOP concepts in languages without using an AOP compiler.
What's written in this section could be wrong. It conveys my understanding of AOP as I study it. As I study, my understanding evolves, & so will my words here.
I still don't know precisely what an aspect is. The best description I have is that it is a way of grouping code which is related but which, in a purely OO programming system, would be separated, scattered around an application. Oft-sited examples of unquestionably good aspects are synchronization policies, authentication, session management & user preferences.
These thoughts are excerpts from an e-mail I sent.
Pavel wrote:
I have a nagging suspicion that AOP is synonym to Policy-Based Programming (PBP), also formalized as Strategy pattern (I hope I quote the right gang-of-4 pattern).
I think you've named the right pattern, & I think your suspicion is a good one. Once you said, it, I could immediately see similarities between what little I know of aspects & Policy Based Programming.
I can also see one thing aspects can do that I'm not sure could be easily donw with the Policy pattern. I still haven't seen a real aspect in detail, but what I have read hints that you can define an aspect & your aspect language (or framework) will automagicaly attach it to ``cut points''. It sounds like cut points can be placed on methods, & most AOP systems assume a method's name identifies a cut point. In other words, you might define an aspect that has a chunk of code that should be executed immediately before every ``readDatabase'' method & another chunk of code to be executed immediately after the ``readDatabase'' methods (maybe the chunks lock & unlock the database). Then, a ``readDatabase'' method on any object, anywhere in the hierarchy (or any of your hierarchies) will automatically execute the aspect's ``before readDatabase'' code & ``after readDatabase'' code. And the aspect can be defined after the ``readDatabase'' methods in your app.
To achieve that functionality with the Policy pattern, I think you'd need to call its methods (or create an instance or however your programming language does it) within each of your readDatabase methods.
Am I missing something? Is there some other way that Policy could be used to get that ``define chunks of code after the fact & outside of methods'' functionality?
Here's a thought about AOP from what I wrote (above) about aspects: If a method's name defines a cut-point, & maybe if programmers can force other cut-points onto methods by name (maybe by attaching cut-point labels to methods - can't do it in C++ or Java directly, but some kind of preprocessor might do it, or some run-time library might offer the feature. You could do it easily in Lisp, neener neener.) Anyway, so let's say cut-points have names & you can apply those names to methods so that your aspect system can figure out what chunks of code from what aspects to apply to the methods. That means that in a large system you'll need to define conventions by which cut-points are named & applied. As we know from the conventions we have for class names & method names, the ``cut-point name'' conventions could themselves become problems.
(The previous paragraph was somewhat speculative of me. I know that AOP has ``cut points'' & that the AOP system uses them to figure out how to match aspects with methods, but I don't know for sure that cut-points have names or even that they can be explicitly applied by programmers to methods. Also, for all I know, you don't apply a cut-point name to a method as a whole; you apply it at a specific location within the method, just like a line of executable code. If so, then the Policy pattern could provide AOP functionality because placing a cut-point name in a method would be just about exactly the same as calling a method on your Policy (or creating a Policy instance or however it's done in your language of choice).)
``Aspect-oriented programming: Introduction''.
It turns out that this article is an introduction to the AOP special section of an issue of Communications of the ACM. It's not an introduction to AOP. No need to read it.
``Separation of coordination in a dynamic aspect oriented framework'' sounds like exactly the type of article I seek.
It's pretty good, though dry & ponderous. I've found one cool concept in it so far. They've given a hand-waving description of what an aspect is, & it has me imagining ways to implement it. Also ways in which it'll bite you in the ass when you try to use it in a big program. (Isn't that how ALL programming techniques work? Looks great in the examples, probably does save you some time in a big app, but it WILL bite you in the ass once in a while.)
Another interesting idea in that article is that AOP languages, which use a compiler (or post-compiler) to inject AOP into the object code, are inferior to dynamic composition of aspects. They point out that if you do static aspects, you loose all the aspect information at run-time. The idea appeals to me probably because I prefer dynamically typed languages.
The rest of the article is not as interesting or useful. It describes the architecture of the authors's online meeting system (or conversation system or crippled MUD, as you will). It describes the functioning of two or three aspects that encapsulate the spaghetti in their application. It does not explain why they are aspects & not objects.
in progress
Pointcuts & Advice in Higher-Order Languages
At last an article I can recommend highly.
This article discusses ways to apply AOP to functional languages or to implement AOP in functional languages. It uses Scheme for its examples, but it's not specifically about AOP in Scheme. I've only read the first few pages so far, but it has already defined join points & pointcut descriptor, and it is currently describing a nicely simple & generate way in which programs written in a higher-order language can specify pointcut descriptors.
todo
Composing crosscutting concerns using composition filters
I am unable to download the PDF of this fucker. It locks up my browser (Mozilla). Surprises the hell out of me. My browser should just send it to a file, not interpret it. Whatever. It's fucked.
I guess I'll have to read the HTML version. Thank god there is one.
to do
Separation and composition of concerns in the object-oriented model
todo
``Aspect-oriented programming''. Appears to be an introductory tutorial, though it uses AspectJ for its examples.
I have a local copy.
todo
``A theory of aspects''. The title is interesting, but the abstract says it's about a particular, theoretical, idealized AOP language.
todo
``Parametric introductions'' appears to be a survey of AOP implementations, though possibly only about languages.
todo
The ``Language-independent aspect-oriented programming'' describes a system called Weave .Net. Sounds like it's a library for .Net languages. Hopefully contains suggestions for implementing AOP as a library or tools for other languages.
todo
``Aspect-oriented programming with model checking'' might be interesting if only because it is a short paper about AOP.
todo
``Aspect-oriented programming with Jiazzi'' is about a tool for Java, but from the abstract, it sounds like the technique might be applicable to other languages. Sounds interesting.
todo
The title of ``An initial assessment of aspect-oriented programming'' sounds very interesting.
todo
``Does aspect-oriented programming work?''.
todo
``AspectCOOL: an experiment in design and implementation of aspect-oriented language'' is about Aspect COOL, which is an AOP programming language, which is not of much interest to me. I'd rather read about AOP concepts or how to apply them with existing programming languages. Nevertheless, the abstract suggests to me that the paper will discuss techniques, not just a new language, so it might be worth reading.
todo
Haven't tracked it down yet. Here's the bibliography information from an article which refers to it.
C.A. Constantinides, A. Bader, T.H. Elrad, M.E. Fayad, and P. Netinant. Designing an Aspect-Oriented Framework in an Object-Oriented environment. ACM Computing Surveys, March 2000.
todo
G. Kiczales et al. Aspect-oriented programming. In Proceedings of ECOOP'97. LNCS 1241. Springer-Verlag, 1997.
todo
G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, W.G. Griswold. An overview of AspectJ. In ECOOP01, June 2001.
todo
R. Pawlack, L. Seinturier, L. Duchien, G. Florin. Jac: A flexible and efficient framework for aop in java. In Reflection'01, September 2001.
todo
Ralf Lämmel's page on AOP foundations: Semantics of aspect-oriented programming.2
Looks like exactly what I wanted, a discussion of the language-independant ideas in AOP.
Need a better definition. Actually, from what little I know, this definition is minimal & accurate, but minimal definitions are not always useful
Advice is the code attached to an aspect.
An aspect encapsulates a feature which, if implemented in an object oriented, imperative, functional, or otherwise non-AOP language, would be scattered around an application's source code & would not be encapsulated.
An aspect associates pointcut descriptors & advice.
Need a better definition.
A join point is a location in a program where the advice from one or more aspects might execute.
The types of locations in the code that an AOP system allows as join points depends on the AOP system, but might include:
AOP systems built on OO systems in which a message send & a method call are separated by more than a single pointer indirection might allow join points when certain messages are sent, or when they are sent from certain methods or objects.
AOP systems built on dynamic or high-order languages might allow join points when:
A pointcut descriptor describes the join points at which an aspect's advice should execute.
The expressive flexibility of pointcut descriptors depends on the AOP system. From what I have read, it sounds like most AOP systems allow pointcut descriptors to include method names & notes about whether the advice should execute before, after, or around the method.
Other join points that many AOP systems might allow in pointcut descriptors include:
Dynamic AOP systems might also allow pointcut descriptors to specify join points as:
The Aspect-Oriented Software Development web site is http://aosd.net/.
This document is available in multi-file HTML format at http://lisp-p.org/naop/.
This document is available in DVI format at http://lisp-p.org/naop/naop.dvi.
This document is available in PostScript format at http://lisp-p.org/naop/naop.ps.