Skip to main content

Why I Fear Aspect-Oriented Programming

Posted by danmil on March 31, 2004 at 9:20 AM PST

Aspect-Oriented programming gives me a bit of the heebie jeebies, I have
to admit. The longer I've programmed, the more I've come to value clarity
over flexibility -- not that they're necessarily in conflict, but if
there's even a hint that they are, I come down on the side of clarity every
time. As I write new code, I tend to find myself obsessively asking: "How
clearly will this code state what it does to someone who reads it?". This
is a lesson from bitter, bitter experience. Maybe some of you reading this
are lucky souls who do nothing but write new code which you never have to
revise, in which case, god bless. I, however, seem to spend much of my
working life reading and revising code which was written long ago by
someone else (or by myself long enough ago that it might as well be someone
else in a galaxy far, far away). Kernighan and Pike, in their brilliant
"The Practice of Programming", extol the great virtues of Simplicity,
Clarity and Generality, in that order. These virtues make code easier to
read and understand, which is about as useful a metric as I can think of
for code quality.

My big fear with AOP is that it adds cool-seeming flexibility ("Look, I
magically added logging to your class without touching the code!" "Wow!"),
while trashing simplicity and clarity. If I'm trying to understand a bug
(or even a working feature) in a chunk of normal Java code, I can look at
the methods which are being called. I may have to play some games with the
inheritance hierarchy, but at least the class definition tells me where to
look (and, as a side note, avoiding these sort of confusing games is
exactly why we should, as the wise Gang of Four say in "Design Patterns",
prefer inheritance of interface over inheritance of

AOP destroys all this -- now, if I want to understand what is happening
at some point in my application, I have to read not only the class methods
being triggered, but also all the aspects and pointcuts and advice
and everything in order to find the relevant bits of code. This
sounds like a recipe for disaster. I routinely get confused reading a
class which inherits a few fields from a superclass -- I can't imagine the
difficulty of comprehending something which pulls bit of behavior from a
dozen different files, with no external hints as to where to look. I'm
getting nervous just thinking about it right now!

I can see how AOP would be useful for some development-cycle
tasks -- adding temporary tracing facilities, or putting in place
instrumentation for testing. These are features which are put in place and
then removed. No one has to come along later and guess that they're
there. But as a means of adding long-term functionality to an application
which will need to be understood, revised and debugged many times over its
lifecycle, it scares the bejesus out of me.

Related Topics >>