The basic idea behind AOP is separation of concerns. By "concern" I mean, roughly, a "bit of functionality". You want all you logging in one place. You want all your DB functionality in one place. You want all of your persistence layer in one place. Etc.

The basic idea of AOP is that decomposition into classes in a classic OO design/implementation can miss some separation of concerns.

The classic AOP example is logging. If you have a system where you are required to log each method entry and exit you need to do something like:

sub foo {
  my $self = shift;
  $self->logger->log('entering foo');
  ....
  $self->logger->log('exiting foo');
};
[download]

to every method. This has two problems:

• It's a lot of monkey coding. Easy to make mistakes. Easy to miss a method out.
• The "concern" of "every method should log entry and exit" is spread out over the entire codebase. It isn't in one location. If you decide that you only want to log method entry you have to go change every method call.

In AOP you can have a single aspect that says "add this logging code to every method". No monkey coding. No possibility of missing anything. The concern is documented in one place. If you need to change what is logged, or what methods/classes logging should happen in, you only have to change one thing.

Introduction to Aspect Oriented Programming with AspectJ has an overview of some of the Jargon, although (obviously) Java oriented. There is also an mp3 of the lightning talk that Marcel Grunauer gave on Aspect at YAPC::North::America 2001.

AOP can be useful in static languages since it can provide you with a lot of additional flexibility (e.g. you can use AspectJ to add mixins to Java). They are of less relevance to more dynamic languages - especially those with a decent meta-class system. Although, on the Java side, aspects are a compile-time concept so they can be very efficient.

AOP can also make testing and debugging harder (IMO).

I have occasionally found AOP useful in debugging. For example Fun with Hook::LexWrap and code instrumentation could be viewed as AOP.

This looks like a kind of parse tree filter, as opposed to source filter. Whenever you have a function in the tree you add something to it.

It depends. You can certainly implement it like that (that's basically what things like AspectJ do).

You can also do it dynamically at runtime (e.g. with Hook::Lexwrap in Perl - which is basically what Aspect does.)

What a full AOP system gives you is the ability to do it in a structured way - making maintenance less of a nightmare.

Perhaps stereotyping the behavior of a set of methods/functions could be handled just as well by Attribute::Handlers ?

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

That's certainly one approach. You could write something like:

use My::App::Logging;
....
sub foo : Logger {
  ...
};
[download]

and the logging functionality is encapsulated into My::App::Logging, and the attribute handler wraps the method appropriately.

However, an AOPer would comment that you lose some of the benefits that an aspect based approach would give you:

• You still have to add the handler to every method you want logged. If you change the policy on what should or should not be logged you still have to do a lot of manual work.
• You lose the benefit of having the logging "aspect" documented/implemented in one place.

Could you elaborate a bit what you meant by "static language" versus "dynamic language"? I don't think I understand. Thanks.

Could you elaborate a bit what you meant by "static language" versus "dynamic language"? I don't think I understand. Thanks.

I was searching for a more diplomatic term for the LFSP/LFM divide :-) Perhaps some examples will illustrate.

---

In an language with metaclasses you can isolate behaviour to a metaclass in a similar way to the way you move behaviour to an aspect. For example, in Python you could add behaviour to object initialisation by creating a custom __init__ method in a metaclass. See A Primer on Python Metaclass Programming for an examples.

In languages with eval() like functionality you can make runtime changes to your codebase. Perl developers regularly do code generation at compile time. In languages like Java this is impossible. Aspects give some of this power to Java.

In languages that support mixins and other forms of multiple implementation inheritance you can separate out some concerns into separate class-hierarchies.

---

If you have mixins, metaclasses, macros, runtime access to your language, etc. you find that you need aspects less. Many uses of aspects in languages like Java are to get around issues with Java's design (e.g. the use of AspectJ to create mixins).

This isn't to say that AOP is a useless or unoriginal concept. There is still the core difference from normal OO code in that an aspect imposes a behaviour on a class, rather than a class requesting behaviour from an aspect.

However, IMO, the arguments for AOP are less compelling when your language is more flexible.

Usually, when static vs. dynamic is discussed, it's referring to the typing of the variables. Perl doesn't require that you declare whether you're using a number or a string ahead of time. That's dynamic typing. Static typing is like C or Java, which makes you say "This variable will always be an integer or a float (or whatever)".

It can also refer to the fact that Perl is (somewhat) introspective, like LISP, while C/C++ is not. You can dynamically generate executable code in Perl, because it's interpreted. You cannot do that in C++. (Well, that's not entirely true, but it's close enough for this discussion.)

Hope that helps!

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.