(AspectOrientedProgramming is patented, it would seem: http://www.pmg.lcs.mit.edu/~chandra/publications/aop.html)
Advanced preprocessing, where you can say things like: "Take every method that starts with the word 'test', and add it to a list of methods to be run when testing." Allows one to centralize CrossCuttingConcerns that would otherwise appear in many different classes.
AOP is motivated by "SeparationOfConcerns". It enables abstraction and modularization of a different kind than OOP provides.
If we look back, using POP (Procedure-Oriented Programming), we must deal with all the concerns in a line. Though we can outsource the code into different functions, the main stream still controls all the process. This is the linear model. When OOP is introduced, we can present the world in a more natural way by describing different objects and their functions. Connections between different objects form a network, a matrix of type vs. behavior. This can be called the two-dimensional model.
Aspect oriented programming allows one to pick out a set of "join points" within the program, and then specify code ("advice") that should run at each of these points. The set of join points is specified in the same place as the advice, keeping aspects modular. This is in contrast to multiple-inheritance object systems like CLOS or C++, where the invocation of behavior is specified by the caller, not the callee.
This allows one to achieve OnceAndOnlyOnce in a new way. When a UserStory is going to affect a lot of classes, describe once in an Aspect and it can affect a dozen or more different places in code. The tools distribute it to the right places. This allows one to create new views into the software system which modularize the story.
A: I don't know how much of an answer this is, but I'm working with a team using MixedCodeGeneration with VbClassic and VisualBasicForApplications to (among other things) embed standard error handling code throughout a program, and allow the generated code to be regeneratet/replaced later. Later on, we'll be automatically generating the target tags for expansion. Sounds a little like AOP, eh? In this case, we're using a cross-cutting technique for error handling because the language does not provide another way to remove duplication of error handling code in procedures. -- SteveJorgensen
Q: How does AOP interact with (regular) refactoring? Most refactorings involve moving code across method boundaries, but when aspect code is potentially triggered on any method invocation, then such refactorings are no longer behaviour-preserving. AnswerMe, please. -- AndersMunch
A: See AspectOrientedRefactoring.
Q: What advantage does AOP give me over OOP? As every time I hear about crosscutting concerns, weaving etc. I keep thinking I could create a singleton agent/server class to handle that aspect of the software as long as its public interface was good enough.
A: One answer might be that AoP allows the application code to be "oblivious" to the aspects woven in, whereas what you propose suggests the need for the programmer to actively (remember to) invoke the aspect server at all the appropriate times/places from within the application code. Your mention of "its public interface" prompts recall of the "built-in" AoP provided by .NET by means of attributes/interfaces. That actually raises the distinction between "black-box" and "clear-box" AoP; equating AoP with only the former perhaps tempts one to question the added-value of AoP over OOP. The book "Aspect Oriented Software Development" by Filman/Elrad et al discusses this. In AOP, one wants a separation (localization) of concerns (away) from the application-domain "component code". Here is the essence of AOP, which differentiates it from, say pre-processor macro wizardry, and other stuff:
AOP: Make "quantifiable" statements: "In component code P, whenever condition C obtains, perform action A"... ...where P is oblivious Definitions: - Quantification: basically, instantiatable delimiting expression - Obliviousness: no need for preparation/modification of P for aspectsWhat differentiates "native support" for AOP in Microsoft's .NET (e.g., see <http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx>), from AspectC++ and AspectJ, is that the former is "black-box" AOP, whereas the latter two are "clear-box" AOP. Black-box allows aspect quantification over the *public interface* of component code (e.g., message interception based), whereas clear-box additionally quantifies over the internal (e.g., private) parsed structure of the component code (i.e., requires a near-compiler).
The power of AspectOrientedProgramming
Recently, I saw a little example of changing behavior at the meta level [http://www.parc.xerox.com/spl/groups/eca/pubs/papers/Kiczales-Andreas-MOP/]. Until then, I'd thought that meta level work was not terribly behavioral... the stuff of database people and modeling language designers. The power of being able to say that method invocations will work differently for a class of classes, or even the way that member variables are associated with an object seems phenomenal. If this sort of behavior change at the meta level thing is all that it seems to be, it could usher in much more clarity in code. -- MichaelFeathers
One (simplified but useful) way of thinking about the techniques (as opposed to the philosophical goals or motivations of) Aspect Oriented Programming is that they put the power of a good debugger into your programming language. A good debugger allows you set actions (print some variables, stop, etc.) whenever a particular variable is accessed or modified or whenever the call stack looks a particular way. Similarly, a good Aspect Oriented Programming language allows you to set up replacement and/or pre/post actions (call this logging procedure, use this cached variable, etc.) whenever a particular variable is accessed or modified or whenever the call stack matches a particular pattern (gets() just called, for example). And because it's in the programming language, these constructs (which can sometimes be too slow to use in a debugger) can be made very computationally efficient.
You need only see a couple examples to realize how powerful and useful this can be. You can then treat some of the rest of the ideas of Aspect Oriented Programming as trying to tame these powerful constructs into something that won't frequently shoot you in the foot (much like Structured Programming tamed the wild goto statement).
The "I Want My AOP" (http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html) articles on JavaWorld do a great job of introducing AOP concepts. It's more complicated than can be effectively communicated here. There is a mental shift that happens in order to understand AOP - sort of like the same shift that happens when you learn OOP for the first time (after programming in a procedural way). -- KenLiu
I don't know this stuff too well, so better explanations are invited. One thing that struck me - leading on from ActiveObjectModel - was the range of techniques they used to implement their approach, which included things like reflection and MetaObjectProtocol(s). It does seem to be about making implicit details explicit. -- DaveHarris
All of the theory is nice, but AspectOrientedProgramming doesn't quite fit my dream environment, which would allow me to filter the aspects of the program I'm working on, by using fonts, italics, colors, etc. to show visually what is which aspect of given source. I believe that AOP should be woven into the IDE of Delphi or some similar language, and things can REALLY take off. -- MikeWarot
Good books on AspectOrientedProgramming and related topics:
AOP is merely another patch to cover one of OOP's numerous shortcomings. First isolate everything into a tiny package ... oh wait! now I need to relate and share things ... I know! I'll make dynamic tags at runtime. Yet another mega-overhead reflection based substitute for table design. Why not store the object relationships and tags and aspects in a table and spare us this nonsense? Tables are dynamic, they are easily grokked, you can instantly change an entire suite of object aspects in a simple sql: (update object_aspects set logging=1 where objectId in (select objectID from object_methods where method_name='Speed'). Which is better, this or manually searching through 30 objects and setting an aspect on 15 of them?
Boom. One line of code and every aspect on a filtered set of objects is changed. What a revolution! This is not new technology, it's a hack to OOP.
I'm going to assume the above rant was by Top, who detests all things Oop... the problem is that the actual relational code must be written in a language. SQL is absolutely appalling for code reuse and collecting like-code together - which, surprise surpise, is why we need better structures for the programming languages themselves. Wouldn't SQL be nicer if you could easily add the same functionality (like an exception handler or something) to every single stored procedure within a given package, without adding the same line of code to each and every sproc?
To me the problem with the term "Aspect Oriented Programming" is that it focusses on the intent, not the methodology. Object-oriented programming is a literal description of the mechanisms involved, as is Functional or Relational programming. To me, aspect-oriented programming is really just class-metaprogramming (or procedurally-constructed classes, or whatever you want to call it) - classes that are constructed based on the features of other classes. Inheritance and generics being the most primitive forms of class metaprogramming - templates being slightly more sophisiticated, but being limited by their inability to handle the members of it's class arguments as collections of the argument class' features. Mixins are similarly limited, being a subclass of templates. The only true "AOP-enabled" functionality in most languages, it seems, codegen-through-reflection - which is occasionally done in Python, C# and Java, however in the latter languages it is generally a challenging undertaking.
I believe that a great number of very interesting things will come out of studying type-systems that will be very relevant to AspectOrientedProgramming. Specification of join points, cut points, advice, etc. can be arbitrarily more sophisticated than they are today. In using advanced types, we'll provide better means of identifying and specifying useful transforms, and grow ever closer to modifying whole processes and systems of processes as true, FirstClass objects. (Among other things, it might be possible to write an AspectOrientedOperatingSystem?.) Studies into SubStructuralTypes? (that delimit the use of values across space and time) and behavioral types (protocols, emergent behaviors, etc.) and Policy/Purpose types (that abstract the 'why' to a particular operation, define 'value' for computations, etc.) and more are essential to bringing this to full power.
JavaLanguage could have been the ideal language for this - Java 1.1 implemented the minimal subset of features required for implementing an OOP concept, but with nearly no features added to ease code-reuse. Said code-reuse could have been the domain of external tools. That could have let it be the ideal target for class-metaprogramming... unfortunately, Sun never officially included such metaprogramming tools, leaving it up to a mishmash of 3rd parties, and so people ended up in the horrific ghetto of verbose hand-written JavaLanguage.
AOP is just what Python calls "decorators", along with some extra magic to specify where to apply a decorator.
After reading the full page, I must admit I still see AspectOrientedProgramming as a hack to OOP. Certainly, hacks can be of value to manipulate the code after it is compiled (for instance to plug security separately from the source coding when it is done ) or to work at the meta level (i.e. the definition of classes), but well, it is strange so few of us need this kind of programming. If OOP was a success, AOP let a lot of people a bit puzzled. It is as if a lot of us were feeling something was going on there, something intellectually interesting but something that is still not worth using :-) Indeed, I never needed AOP to solve a problem that could not be solved by standard design patterns. I imagine I don't write the adequate kind of code to understand the full interest of it. But I come back to it from time to time since I saw the first demo in INRIA back in 2000 or so. --OlivierRey