Aspect-oriented programming (AOP)

Update: There will be at least one presentation on AOP at the SystemVerilog Requirements Gathering Meeting on Feb. 26.

AspectJ, an extension to Java, is the de facto standard for aspect-oriented programming (AOP). It was developed at Xerox PARC by a team led by Gregor Kiczales.

In 2003-2004 he wrote a series of a dozen columns about aspect-oriented programming (AOP) in Software Development.

In 2006, he gave the following Google “TechTalk”

He ended up running out of time. If you’re running out of time, you might want to skip directly to 38:00, perhaps after skimming these slides from 2004 and reviewing the Observer pattern.

He says about AOP consultants and the practical intuition of crosscutting

They’re not bothering to say, “… I have to go live in that code”.
They’re saying, “I’ve got a library of pointcuts that gives me a meaningful abstraction of that code, I can just cut through it, program against those pointcuts, and know interesting things right away.”

More controversially, he disputes Barbara Liskov, saying

Social practice is very clearly at conflict with the story we tell about encapsulation.


The current story we tell about modularity is bunk.

He says

One of the classic adoption strategies … is to start by doing architecture enforcement, you don’t write any aspects that ship in the running product.

The abstract from here is

Google TechTalks May 16, 2006 Gregor Kiczales Gregor Kiczales is Professor of Computer Science at the University of British Columbia. His work is directed at enabling programmers to write programs that, as much as possible, look like their design. ABSTRACT Aspect-oriented programming (AOP) is based on a radical exploration of modularity in software development. By presenting new mechanisms that enable better modularization in a number of systems, AOP is driving us to ask fundamental questions about what modularity should mean in our field. In the past, we have tended to think of modularity in terms of hierarchies of crisply defined blocks, where each block or module defines its interface with the surrounding modules. This idea seems attractive but experience tells us that it is hard to actually get the modularity of the software we build just right. Some issues are hard to code (or design) in a single module, others just don’t seem to want to stay where you put them. Work in AOP and other areas suggests a different conception of modularity, based on crosscutting structures and a more fluid notion of module boundaries. The talk will present existing AOP techniques and the problems they solve, as well as open practical and research problems ranging from mechanisms, to applications, to theoretical formulations and to conceptual foundations.


Tell me (anonymous OK)

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s