The Father of AOP
Gregor Kiczales, a force in the creation of aspect-oriented programming, spoke with eWEEK Senior Editor Darryl K. Taft about the history and future of AOP. Where did aspect-oriented programming come from? What is it?At the end of the day the systems are too big to think about them at the micro level. And aspect [AOP] is really just a next step in structuring mechanisms. Now you know objects didnt replace procedures; they just kind of gave a higher level structuring mechanism. And aspects dont replace objects; they just gave another kind of structuring. And if you listen to what people say theyre doing with aspects, thats really what its all about. For example, when people say, "I can ship my system with six different logging policies," what theyre saying is, "I was able to structure my system so that logging is a separate aspect of its behavior. And in fact I have six of them." So if you want to think about it in terms of structure or you want to think about it in terms of modularity, those are two ways of saying the same thing. And its really about saying, "Is my big, huge, vast system one big knot that I cant take apart and that I can only think about as one big knot? Or is my big, huge, complicated system a collection of subpartssome big subparts that have smaller subparts? And can I think about my system as saying, well, you know I can take this part out and put a new part in, and my system behaves a little bit differently but in a way I understand." So whats an aspect? An aspect is a particular kind of part that has this notion of cross-cutting behavior. And the way to think about cross-cutting is it means that it affects lots of the systems activities. So if you have some enterprise Web application and you add a new field to the account record, then you know what thats going to do. Thats going to add a new field to each account. Thats a fairly localized effect. But if you say, "I want to wrap some security around access to all parts of all account records," thats a cross-cutting effect in that it touches a bunch of things in a uniform way. And thats what its all about. Its that systems have reached a level of complexity where we want to pull out those aspects. If you look at enterprise Java, where its the first place that aspects are getting a lot of application, its exactly because the people making those kinds of systems are aiming to make various things pluggable. Like they want to make security pluggable. And by pluggable, I mean you want to be able to swap different ones in and out. They want to make persistence pluggable, they want to make logging pluggable. And those are just classic aspects. AOP brings power and simplicity to complex systems. Click here to read more. Lets go back to the beginning. You were part of a team that created AOP? Like all ideas of this kind, different groups in different places were kind of working in this space. My group at PARC [the Xerox Palo Alto Research Center] is generally credited with having crystallized the simplest version of it, but there were other people who were right in the same space. There was a group at IBMHarold Osshers group, for example. But we had a group at PARCmyself and John Lamping were the principalsand we were trying to figure out expressivity. We wanted to write programs that were simple and clean, and what we had noticed was when you had these cross-cutting concerns, your programs werent simple and clean because you tended to have some code and then the same thing would appear in 22 different places. And every time the same thing appears in 22 different places, thats just a disaster waiting to happen. Because you might forget the 23rd, or somebody might decide to change something and only fix 21 of them. And we kind of zeroed in on this notion that theres this cross-cutting structure, and we made this language that got a handle on it. So, did you have a particular platform or environment in mind? Were you targeting Java? We actually started prior to Java. And then we got ourselves to a place where we thought we understood what we wanted to do well enough that it was time to do a real version of it. And just at that moment in time Java was coming along, and we decided that Java was the place to do it. Because, since there was no legacy Java code, we felt people would be open to new ideas. So we started AspectJ with Java in mind, and then AspectJ was kind of a restart of the whole AOP project for Java. But we already knew that the idea of AOP wasnt particular to Java. What time frame was this? When we started AspectJ, it was about 1998. And when you started the AOP project in general? It depends on how you count, but I think the first time we used the words "aspect-oriented" was 1995-1996. But wed been working in this space since about 1986 because we were doing reflection, but we decided that was probably too powerful for anybody to use, and certainly too complicated for a wide swath of people to use. It was because you could do this with reflection that we realized you could do it. And then the challenge was to then make it comprehensible. Page 2: The Father of AOP
If you look at the evolution from machine code to procedures like Algol and Pascal, to objects [object-oriented languages] like Smalltalk and Java, those are evolutions about helping architects and programmers structure complicated systems.