Aspect-oriented Programming comes to Perl.
I've uploaded an alpha distribution to CPAN, and it's also available from http://codewerk.unixbeard.net/aspects/Aspect-0.04.tar.gz. There is a "perl-aspects" mailing list at http://www.astray.com/mailman/listinfo/perl-aspects.
What is Aspect-oriented Programming?
Aspect-oriented Programming (AOP) is a programming methodology developed by Xerox PARC. The basic idea is that in complex class systems there are certain aspects or behaviors that cannot normally be expressed in a coherent, concise and precise way. One example of such aspects are design patterns, which combine various kinds of classes to produce a common type of behavior.
Another such aspect concerns debugging or tracing the flow of
execution. Maybe every time one of a set of subroutines is entered
or exited, you want to want to print a line telling you so. Normally
you would you the good old 'print' statement debugger, or maybe
you would actually use a custom Perl debugger or a C
You might change the source of all those subroutines you're interested in to print the desired information. When you are done debugging, you remove the print statements again. That's a lot of effort and can lead to bugs and oversights of its own. Furthermore, your code is littered with unsightly print statements. If you want to change the output, you have to change every print statement. If you add a class, remember to add the print statements. It's a mess. Wouldn't it be easier if you could influence the behavior of those subroutines from the outside, like a switch you could flip to make them print a statement when they're entered (in a consistent way, without chance of forgetting to create or remove a print statement), then flip the switch again to turn that behavior off?
That's what aspect-oriented programming is about. Aspects usually concern many classes right across the class hierarchy. One says that they "crosscut the program structure" and refers to them as "crosscutting concerns".
Just like object-oriented programming (OOP) encapsulates the concepts and functionality of individual classes and arranges them in a class hierarchy, so does AOP encapsulate the concerns of many classes and make those aspects or behvaviors reusable. In this way AOP is orthogonal to OOP.
Aspects allow you to change the interaction of objects without breaking their encapsulation. You don't change the behaviors of the objects per se, but rather the way they behave at the seams, at well-defined points during execution. For example, you can intercept method calls, override methods, influence operators, and generally influence the flow of execution in a way that isn't possible without AOP.
Certainly you can achieve all these things without AOP, but it would be a lot harder, less (or, more likely, not at all) reusable and more error-prone. Just as you can simulate any object-oriented program using non-OO techniques, but OO makes things just so much easier.
By modularizing such concerns into aspects you ensure consistent behavior across your project and don't depend on individual programmers to follow a convention, say, on how to write security or error checking. Indeed, it may not be necessary to for individual programmers to write code for such concerns at all, if they're centrally managed, from the outside, as it is, by aspects.
