Aspect Oriented Programming

(AspectOrientedProgramming is patented, it would seem:

Quick description

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.

Longer description

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.

Then AOP comes along and tells us that the change from POP to OOP is not complete and the world need more dimensions. This cross-cutting, distributed code can be seen as interconnections over and beyond the two-dimensional networking that OOP produced. Rules can be well tangled with the objects they govern. If the system is small, it will not be a problem. But if the system is big enough, these crosscutting concerns can significantly bloat the objects, and AOP should be applied.

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.

See also:

External site links: Contributors: Daisy Wang, StanleyKnutson, AnonymousDonor, DickBotting, DaveHarris

Related work

In a sense, AspectOrientedProgramming is the opposite of FunctionalProgramming. The core mindset of FunctionalProgramming is computation without relying on SideEffects; in a sense, the core mindset of aspects is adding SideEffects. Aspects are like the DecoratorPattern applied to functions.

Contributors: multiple AnonymousDonors, IanRae, ChanningWalton, LO

AspectOrientedProgramming QuickQuestions

Q: I develop in VbClassic and other related technologies of Pre DotNet days. If I am not doing WebServices do I need to care about AOP?

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 are some AspectOrientedPatterns?? -- AnonymousDonor

A: ??

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:

Make "quantifiable" statements:
"In component code P, whenever condition C obtains, perform action A"...
...where P is oblivious
- Quantification: basically, instantiatable delimiting expression
- Obliviousness: no need for preparation/modification of P for aspects
What differentiates "native support" for AOP in Microsoft's .NET (e.g., see <>), 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).

Q: Would AspectOrientedFunctionalProgramming? be a useful concept, or is that just silly? Is anyone attempting something like this? -- SteveJorgensen

A: Check out, there is a body of work about AOP and FunctionalProgramming.

The power of AspectOrientedProgramming

Recently, I saw a little example of changing behavior at the meta level []. 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).

-- ThomasColthurst

The "I Want My AOP" ( 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:

See ProgrammingParadigm

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?

ExtendedObjectTcl provides an interesting view of AOP: Mixins. Mixins allow classes to be blended together. The methods of the mixin class are mixed into the the methods of the target class. This allows methods to be added to classes independent of the normal OO class hierarchy. Thus a Bat and a Bird can both have a fly method with the same implementation without forcing all mammals to have a fly method. Mixins may also applied to specific objects as well. This results in elegant code reuse that is not elegant in OO languages. If AOP has any value, it should be a way to reduce complexity overall and reuse code. --BenThomasson

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.

Aspect Oriented tells me nothing about what it is... the only explanations I've found of it have involve class-metaprogramming like the logging example. Objects can be concisely explained in a procedural concept - functions are associated with the struct they apply to, and access to many of the structs features are controlled to within those functions - initialization is forced - and you can base a struct upon another type of struct and thus it becomes substitutable, using it's own functions in the place of the first one. Generic, likewise, can be explained in terms of OOP - designing functionality based on the abilities of a type rather than specifically what type or interface it is, yet maintaining knowledge of what type it is to ensure type-safety. Aspect? Vague notions of "separations of concerns" and trivial examples involving class metaprogramming. I was explaining OOP in the context of C vs the C-OOP descendants, and generics in the context of the generic add-ons to those same languages. Obviously, OOP works differently in other languages. I suppose my problem is that most of the descriptions here are a few levels too far away from the actual processes involved. "SeperationOfConcerns?" is the higher goal, but in practice the main purpose is to keep related code together and maintain OnceAndOnlyOnce - your logging is all in one place, and all you have to do is mark logged classes as such. Likewise, the discussion of "Aspects" themselves is more a discussion of a higher goal, whereas the actual process involved is adding functionality to programming devices (sprocs, objects, functions, whatever) wholly externally to their declaration, generally through preprocessing or other forms of metaprogramming. To be clear: I love AspectOrientedProgramming, and the devices involved... I just think that many of the labels associated with it are too high-level to allow the neophyte to understand what's going on. I suppose I'm just arguing over terminology... which is rather pointless in retrospect.

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

CategorySourceManagement CategoryAspectOrientation

EditText of this page (last edited November 20, 2014) or FindPage with title or text search