12 ms·

Introduction to Aspect-Oriented Programming

57 points by owlish 12y ago

sarahj 12y ago
urggh...is this still a thing? AOP is an idea that sounds wonderful as a concept - "Hey wouldn't you love not to be peppering your code with logic unrelated to the business logic in your code?" Great idea...however, every implementation I have seen is terrible. It makes code nearly impossible to test and audit and, in addition, creates a whole other set of code that needs to be tested and audited. Taking the example at hand. From the first function I have a clear idea of what to expect, when I should see logging and what the failure cases and responses are. Now instead of a 1 line log statement, the article proposes the 7 line meld definition is much cleaner. Where does this code live? Another 7 lines to track the length of the call, opposed to 3 lines in the function. And now I have a hidden entry to my function - before the calling path was clear...calling dial() meant I called dial() now calling dial() means I actually call some random function which, assuming it has been written correctly, calls dial() The error handling is possibly the one redemption here, but still - OO provides you with the tools to encapsulate retry logic just fine without resorting to AOP. I didn't like AOP when I first came across it at University, I didn't like it when I came across some code at a previous employer, and I don't like it now. Nice write up though.
- PeterGriffin2 12y ago
  I guess a few people are still talking about it because it sounds significant, the name sounds as if it's competing with OOP, instead of being the gimmick that it is. We do the same thing in OOP (without the "spooky action from distance" you've noticed) with the Decorator & Strategy patterns, very simple patterns, even those who don't know about patterns are probably using them without knowing.
  - different-opini 12y ago
    There are people, who prefer pure C, without OOP's "spooky action from distance". Just like language support for OOP concepts, AOP gives you a higher level of abstraction to solve complex problems.
    - PeterGriffin2 12y ago
      Thank you for your generic argument, but I can tell you have no idea what AOP is if you'll take that quote, which points out a very specific issue in AOP and apply it to OOP in general. Pray tell, what "complex problem" have you solved with AOP? The only thing people ever talk about is adding logging, tracing and metrics. That's the opposite of a complex problem (and I'd argue AOP doesn't really solve it beyond toy tutorials).
- ExpiredLink 12y ago
  > urggh...is this still a thing? No, fortunately. AOP was relegated to the museum of programming history, section 'ideas that didn't work out' (the largest section in the museum, BTW). > I didn't like AOP when I first came across it at University, I didn't like it when I came across some code at a previous employer, and I don't like it now. Amen.
KMag 12y ago
Apart from logging, it would be good to see a variety of examples where AOP is clearly preferable to dependency injection/IoC. AOP has a bit of a feel of "spooky action at a distance" to it. Extra code is inserted in your code, without you inserting some markers at that point as a clue to the reader. I could see wider adoption for a variant of AOP where the join points needed to be explicitly annotated in the code. However, this would just seem to be first-class language support/syntactic sugar for dependency injection/IoC. There may well be great use cases for AOP, but people need to see examples that justify overcoming the unfamiliarity of AOP. Logging by itself hasn't been a compelling enough use case, and several of the other use cases are almost as well served by dependency injection/IoC without introducing the cognitive load of an unfamiliar programming paradigm. Also, presumably the cognitive load of AOP goes down with familiarity, but how much does the cognitive load really go down? It seems very difficult to reason about code being arbitrarily inserted at arbitrarily defined join points, without the join points being annotated in the code. Are there editors with really good AOP support, so that when programming in the large, programmers can easily see the active join points in their programs and expand them? Without good editor support, AOP seems (at least from my shallow understanding) to be a feature that's very useful in the small, but very easy to over-use in the large.
- mabbo 12y ago
  The software my team works on at work is java based, and make pretty extensive use of aspects with Spring AOP. Generally, I've learned two lessons to reduce the 'what the Fuck just happened here?' problem. First, the method being given the aspect should be annotated. @LogsArgs or @Transactional. None of this 'oh we just use an auto proxy to apply this to every method' bullshit. Tell me you're doing something. Second, the annotation should be and to tell you exactly what it's doing with just the name. @LogRequestAndResponse. What does it do? Exactly what it says. If you can't describe the end result easily, then how will the next guy have a clue what just happened? Whenever I've followed these, I don't regret aspects very often. When I stop following them, people get confused.
  - seanmcdirmid 12y ago
    This is good advice. You do lose the transparency of the approach in this case, but you are otherwise stuck in a higher-order form of callback hell if you don't. Though one wonders if they could get rid of even this if they just had some dynamic scoping.
hexleo 12y ago
The first time I met AOP is I use Spring framework. AOP is a good thing for logging or authorization check, very powerful.
seanmcdirmid 12y ago
> Every time you use CSS, you’re doing Aspect-Oriented Programming Uhm...no. I don't really get how someone could convolute declarative rule-based programming with AOP. Granted, they both deal with modularization (aka separation of concerns), but almost all work in PL does! There is a good reason why the AOSD conference was renamed Modularity. I loathe the day when AOP comes back in style as a 2nd-run fad.
- lightblade 12y ago
  I don't see why you can't have both declarative rule-based programming and AOP.
  - seanmcdirmid 12y ago
    Sure, the only question is "what is AOP?"
- tinco 12y ago
  I agree that CSS is not AOP, but not for the reason you state. From my perspective both CSS and AOP incorporate a declarative rule based programming language. (At least most AOP does). The difference relevant here between the two is that CSS applies its rules over data, and AOP applies its rules over code. (another big difference ofc is that CSS is a DSL whereas AOP is a general purpose technique)
  - seanmcdirmid 12y ago
    Not all systems that have referred to themselves as AOP are rule-based...mostly AspectJ and some annotation based systems are (e.g. Spring). Some systems apply rules over execution, but this is just applying it over code in a different phase (think static vs. dynamic type checking). AOP is not generally described as being limited to rule-based techniques.
hcarvalhoalves 12y ago
Could monadic types solve the same problem in codebases, by letting you compose "business" and "implementation" functions?
- saryant 12y ago
  That's the idea behind the Reader pattern: http://blog.originate.com/blog/2013/10/21/reader-monad-for-dependency-injection/ http://blog.originate.com/blog/2013/10/21/reader-monad-for-d... Essentially, your business logic operations return a function of Implementation => Result, rather than just your Result, and you then call the function with whatever implementation you need at the edges of your application.
makmanalp 12y ago
AoP strikes me as one of those things where someone just invented a bunch of terminology around a really basic concept, for no good reason. Aspect? Advice? Joinpoint? Pointcut? Really? As far as I've been able to understand, AoP is just hooks. You can hook something before or after a function, or 'around' it which is a combination of both. Super useful, but really not that amazing or novel. Definitely does not warrant its treatment as some kind of separate type of programming. ... Small nitpick with the article: In the example given, the call timing uses 'around', which measures the entire function as opposed to just the part of it that the initial function was measuring, right?
- girvo 12y ago
  It really reminds me of Wordpress' hook system... And that makes me want to run away screaming, as the maintenance and testing nightmare that that entails has easily removed a decade off my lifespan.
- ajkjk 12y ago
  We use a lot of AOP at work and explaining all the arcane terminology to new engineers is always a nightmare .. but it's necessary to work with basic libraries. So I totally agree.
- rtpg 12y ago
  well, in AOP you can describe situations such as "when f is called within g". I think it's a lot more complex than just hooks. Whether this extra descriptive capability is a positive thing is an open question (well, considering AOSD (Aspect-Oriented Software Developement) confernce changed to Modularity, maybe the question has been answered negatively)
- nmrm 12y ago
  I think a lot of the research around AOP was doing all this stuff, but with static checking. Which gets less trivial pretty quickly, and the distinctions become necessary. But I agree in spirit.
  - makmanalp 12y ago
GarvielLoken 12y ago
Multi-Dimensional Separation of Concerns is more useful and can easily be modelled in standard oo without tools. In a game for example you can have three dimensions, data, features and system dimensions. Where each is a folder hierarchy in your solution. Here you use the standard oo cross dimension with interfaces. Like system dimension export interface IGUI which exposes return actions and info functions that features and the data dimension classes can implement. But you can also make a feature cross dimensional by using partial classes. So if you want to add a new feature, let's say Move you add a behaviour class in the feature dimension, in a new folder, which implements interfaces from the system dimension like Igui and Igamestate and uses a TroopDataClass from the data dimension. Then you make a new folder in the data dimension and make a partial class for TroopDataClass where you add move based data like petrol. Now that whole feature is isolated, you can easily remove both Move folders and nothing will break everything will compile just as before. The advantage is that you get rid of the spiderweb dependencies you get if Move where a standard class with combined data and behaviour. For data that still is feature crosscutting like ActionPoint or Position on the map, you can still use inheritance and standard oo techniques within the Data dimension, so TroopDataClass inherits from MapObjectClass or something similar, then all features will have access to them. http://www.cs.bilkent.edu.tr/~bedir/CS586-AOSD/Syllabus/NDegreesOfSeparation.pdf http://www.cs.bilkent.edu.tr/~bedir/CS586-AOSD/Syllabus/NDeg...
- seanmcdirmid 12y ago
  Or you could use mixin layers or virtual classes, or open class patterns. There is literally a million ways to do this. Today, I use partial classes and approximated mixins (C# doesn't have real mixins).
Dewie 12y ago
It would be cool to see a comparison between AOP and the monad stacks of Haskell.
michaelcampbell 12y ago
I've bought into the AOP thing a couple times, and every time it has bitten me (or my coworkers) in the ass. I fully admit that it may be too much power for mine (and colleagues) small brains, but has anyone ever actually seen AOP work, in practice? It sometimes reduces coding efforts, but it is the living embodiment of the saying, "If you're as smart as you can be when you write it, how will you ever debug it?" It's just too much magic spread over too wide an area. I'd much rather have more explicit patterns being used that people can understand, find, reason about, and debug - code reuse is a means to an end, not the end itself. Again, maybe I'm just not enlightened enough.
- acjohnson55 12y ago
  So much AOP negativity on here. I haven't specifically used AOP in a project, but I do recognize huge value in its concepts. Many of the techniques here also have other names in other traditions, but if you get past the rather awkward terminology, the concept of factoring separate concerns into reusable and independently testable chunks is really useful, by any name.
  - michaelcampbell 12y ago
    My negativity comes from experience. I also like the theory and concept of it, but I haven't found it to help in other than very specific circumstances, and quite destructive in time and understanding when used even slightly outside those. Terminology had nothing to do with the issue, in my particular experience.
- blablabla123 12y ago
  Once had a job interview at a software consulting company. They had a number of finished projects for high profile customers and they claimed that they use AOP for their projects. Turned down the offer though because I didn't like the people too much. ;)
- tinco 12y ago
  I've applied the technique in a project once with a pretty nice effect. I think the key requirement for AOP is that your code really is very clean, and to never influence logic in your main code in any other way than stopping it. I.E, if you insist on catching exceptions in your crosscuts, don't go trying to fix the exception by modifying state. Either kill the thread, or let the original logic deal with it. Our project was a bit of a laboratory environment. It was a university course that meant to test our ability to apply Patterns of Software Development (i.e. GoF) by having us implement a board game called Bohnanza (basically a heavily simplified Magic: The Gathering). Our approach was to fully focus on implementing the business logic in a correct and test-driven fashion. In the weeks we spent on implementing the business logic we never implemented any GUI. Then when it was done instead of polluting the business logic with the traditional MVC architecture, we designed a GUI that was layered on top of the business logic through AOP. The GUI was just observing through cross cuts the transitions of the games state machine, rendering the relevant game elements and making available the valid inputs. We were one of the few teams who managed to have both a correct game logic and a fully functioning GUI as well as a test suite with good coverage.
FranOntanaya 12y ago
I've found myself wanting at times to keep logging outside the fuction, but then I realized I would have to write a lot of extra comments to fill in for the documentation the logging itself provides. As long as the logging logic itself is kept elsewhere, having logging instructions within the code is not an obstruction. Logging events themselves can have semantic value, as they would often mark some key point in the execution.
dcre 12y ago
Nice writeup, though I was struck by the author's funny use of the word "concerns": > Remember that AOP aims to separate concerns from business logic ... It turns out that nearly half our function code is devoted to concerns! Separation of concerns is about separating concerns from each other, not from business logic. Business logic and logging are both concerns. It doesn't ruin the article or anything, it's just an interesting mistake.
yazaddaruvala 12y ago
I've always wondered why only Java seems to have this concept. I haven't quite dug into a "real" macro system (I don't mean the c macro system) but is it that a good macro system is able to replace("emulate") AOP?

57 points by owlish 12y ago

urggh...is this still a thing? AOP is an idea that sounds wonderful as a concept - "Hey wouldn't you love not to be peppering your code with logic unrelated to the business logic in your code?" Great idea...however, every implementation I have seen is terrible. It makes code nearly impossible to test and audit and, in addition, creates a whole other set of code that needs to be tested and audited. Taking the example at hand. From the first function I have a clear idea of what to expect, when I should see logging and what the failure cases and responses are. Now instead of a 1 line log statement, the article proposes the 7 line meld definition is much cleaner. Where does this code live? Another 7 lines to track the length of the call, opposed to 3 lines in the function. And now I have a hidden entry to my function - before the calling path was clear...calling dial() meant I called dial() now calling dial() means I actually call some random function which, assuming it has been written correctly, calls dial() The error handling is possibly the one redemption here, but still - OO provides you with the tools to encapsulate retry logic just fine without resorting to AOP. I didn't like AOP when I first came across it at University, I didn't like it when I came across some code at a previous employer, and I don't like it now. Nice write up though.

PeterGriffin2 12y ago
I guess a few people are still talking about it because it sounds significant, the name sounds as if it's competing with OOP, instead of being the gimmick that it is. We do the same thing in OOP (without the "spooky action from distance" you've noticed) with the Decorator & Strategy patterns, very simple patterns, even those who don't know about patterns are probably using them without knowing.
- different-opini 12y ago
  There are people, who prefer pure C, without OOP's "spooky action from distance". Just like language support for OOP concepts, AOP gives you a higher level of abstraction to solve complex problems.
  - PeterGriffin2 12y ago
    Thank you for your generic argument, but I can tell you have no idea what AOP is if you'll take that quote, which points out a very specific issue in AOP and apply it to OOP in general. Pray tell, what "complex problem" have you solved with AOP? The only thing people ever talk about is adding logging, tracing and metrics. That's the opposite of a complex problem (and I'd argue AOP doesn't really solve it beyond toy tutorials).
ExpiredLink 12y ago
> urggh...is this still a thing? No, fortunately. AOP was relegated to the museum of programming history, section 'ideas that didn't work out' (the largest section in the museum, BTW). > I didn't like AOP when I first came across it at University, I didn't like it when I came across some code at a previous employer, and I don't like it now. Amen.

KMag 12y ago

Apart from logging, it would be good to see a variety of examples where AOP is clearly preferable to dependency injection/IoC. AOP has a bit of a feel of "spooky action at a distance" to it. Extra code is inserted in your code, without you inserting some markers at that point as a clue to the reader. I could see wider adoption for a variant of AOP where the join points needed to be explicitly annotated in the code. However, this would just seem to be first-class language support/syntactic sugar for dependency injection/IoC. There may well be great use cases for AOP, but people need to see examples that justify overcoming the unfamiliarity of AOP. Logging by itself hasn't been a compelling enough use case, and several of the other use cases are almost as well served by dependency injection/IoC without introducing the cognitive load of an unfamiliar programming paradigm. Also, presumably the cognitive load of AOP goes down with familiarity, but how much does the cognitive load really go down? It seems very difficult to reason about code being arbitrarily inserted at arbitrarily defined join points, without the join points being annotated in the code. Are there editors with really good AOP support, so that when programming in the large, programmers can easily see the active join points in their programs and expand them? Without good editor support, AOP seems (at least from my shallow understanding) to be a feature that's very useful in the small, but very easy to over-use in the large.

mabbo 12y ago
The software my team works on at work is java based, and make pretty extensive use of aspects with Spring AOP. Generally, I've learned two lessons to reduce the 'what the Fuck just happened here?' problem. First, the method being given the aspect should be annotated. @LogsArgs or @Transactional. None of this 'oh we just use an auto proxy to apply this to every method' bullshit. Tell me you're doing something. Second, the annotation should be and to tell you exactly what it's doing with just the name. @LogRequestAndResponse. What does it do? Exactly what it says. If you can't describe the end result easily, then how will the next guy have a clue what just happened? Whenever I've followed these, I don't regret aspects very often. When I stop following them, people get confused.
- seanmcdirmid 12y ago
  This is good advice. You do lose the transparency of the approach in this case, but you are otherwise stuck in a higher-order form of callback hell if you don't. Though one wonders if they could get rid of even this if they just had some dynamic scoping.

hexleo 12y ago

The first time I met AOP is I use Spring framework. AOP is a good thing for logging or authorization check, very powerful.

seanmcdirmid 12y ago

> Every time you use CSS, you’re doing Aspect-Oriented Programming Uhm...no. I don't really get how someone could convolute declarative rule-based programming with AOP. Granted, they both deal with modularization (aka separation of concerns), but almost all work in PL does! There is a good reason why the AOSD conference was renamed Modularity. I loathe the day when AOP comes back in style as a 2nd-run fad.

lightblade 12y ago
I don't see why you can't have both declarative rule-based programming and AOP.
- seanmcdirmid 12y ago
  Sure, the only question is "what is AOP?"
tinco 12y ago
I agree that CSS is not AOP, but not for the reason you state. From my perspective both CSS and AOP incorporate a declarative rule based programming language. (At least most AOP does). The difference relevant here between the two is that CSS applies its rules over data, and AOP applies its rules over code. (another big difference ofc is that CSS is a DSL whereas AOP is a general purpose technique)
- seanmcdirmid 12y ago
  Not all systems that have referred to themselves as AOP are rule-based...mostly AspectJ and some annotation based systems are (e.g. Spring). Some systems apply rules over execution, but this is just applying it over code in a different phase (think static vs. dynamic type checking). AOP is not generally described as being limited to rule-based techniques.

hcarvalhoalves 12y ago

Could monadic types solve the same problem in codebases, by letting you compose "business" and "implementation" functions?

saryant 12y ago
That's the idea behind the Reader pattern: http://blog.originate.com/blog/2013/10/21/reader-monad-for-dependency-injection/ http://blog.originate.com/blog/2013/10/21/reader-monad-for-d... Essentially, your business logic operations return a function of Implementation => Result, rather than just your Result, and you then call the function with whatever implementation you need at the edges of your application.

makmanalp 12y ago

AoP strikes me as one of those things where someone just invented a bunch of terminology around a really basic concept, for no good reason. Aspect? Advice? Joinpoint? Pointcut? Really? As far as I've been able to understand, AoP is just hooks. You can hook something before or after a function, or 'around' it which is a combination of both. Super useful, but really not that amazing or novel. Definitely does not warrant its treatment as some kind of separate type of programming. ... Small nitpick with the article: In the example given, the call timing uses 'around', which measures the entire function as opposed to just the part of it that the initial function was measuring, right?

girvo 12y ago
It really reminds me of Wordpress' hook system... And that makes me want to run away screaming, as the maintenance and testing nightmare that that entails has easily removed a decade off my lifespan.
ajkjk 12y ago
We use a lot of AOP at work and explaining all the arcane terminology to new engineers is always a nightmare .. but it's necessary to work with basic libraries. So I totally agree.
rtpg 12y ago
well, in AOP you can describe situations such as "when f is called within g". I think it's a lot more complex than just hooks. Whether this extra descriptive capability is a positive thing is an open question (well, considering AOSD (Aspect-Oriented Software Developement) confernce changed to Modularity, maybe the question has been answered negatively)
nmrm 12y ago
I think a lot of the research around AOP was doing all this stuff, but with static checking. Which gets less trivial pretty quickly, and the distinctions become necessary. But I agree in spirit.
- makmanalp 12y ago

GarvielLoken 12y ago

Multi-Dimensional Separation of Concerns is more useful and can easily be modelled in standard oo without tools. In a game for example you can have three dimensions, data, features and system dimensions. Where each is a folder hierarchy in your solution. Here you use the standard oo cross dimension with interfaces. Like system dimension export interface IGUI which exposes return actions and info functions that features and the data dimension classes can implement. But you can also make a feature cross dimensional by using partial classes. So if you want to add a new feature, let's say Move you add a behaviour class in the feature dimension, in a new folder, which implements interfaces from the system dimension like Igui and Igamestate and uses a TroopDataClass from the data dimension. Then you make a new folder in the data dimension and make a partial class for TroopDataClass where you add move based data like petrol. Now that whole feature is isolated, you can easily remove both Move folders and nothing will break everything will compile just as before. The advantage is that you get rid of the spiderweb dependencies you get if Move where a standard class with combined data and behaviour. For data that still is feature crosscutting like ActionPoint or Position on the map, you can still use inheritance and standard oo techniques within the Data dimension, so TroopDataClass inherits from MapObjectClass or something similar, then all features will have access to them. http://www.cs.bilkent.edu.tr/~bedir/CS586-AOSD/Syllabus/NDegreesOfSeparation.pdf http://www.cs.bilkent.edu.tr/~bedir/CS586-AOSD/Syllabus/NDeg...

seanmcdirmid 12y ago
Or you could use mixin layers or virtual classes, or open class patterns. There is literally a million ways to do this. Today, I use partial classes and approximated mixins (C# doesn't have real mixins).

Dewie 12y ago

It would be cool to see a comparison between AOP and the monad stacks of Haskell.

michaelcampbell 12y ago

I've bought into the AOP thing a couple times, and every time it has bitten me (or my coworkers) in the ass. I fully admit that it may be too much power for mine (and colleagues) small brains, but has anyone ever actually seen AOP work, in practice? It sometimes reduces coding efforts, but it is the living embodiment of the saying, "If you're as smart as you can be when you write it, how will you ever debug it?" It's just too much magic spread over too wide an area. I'd much rather have more explicit patterns being used that people can understand, find, reason about, and debug - code reuse is a means to an end, not the end itself. Again, maybe I'm just not enlightened enough.

acjohnson55 12y ago
So much AOP negativity on here. I haven't specifically used AOP in a project, but I do recognize huge value in its concepts. Many of the techniques here also have other names in other traditions, but if you get past the rather awkward terminology, the concept of factoring separate concerns into reusable and independently testable chunks is really useful, by any name.
- michaelcampbell 12y ago
  My negativity comes from experience. I also like the theory and concept of it, but I haven't found it to help in other than very specific circumstances, and quite destructive in time and understanding when used even slightly outside those. Terminology had nothing to do with the issue, in my particular experience.
blablabla123 12y ago
Once had a job interview at a software consulting company. They had a number of finished projects for high profile customers and they claimed that they use AOP for their projects. Turned down the offer though because I didn't like the people too much. ;)
tinco 12y ago
I've applied the technique in a project once with a pretty nice effect. I think the key requirement for AOP is that your code really is very clean, and to never influence logic in your main code in any other way than stopping it. I.E, if you insist on catching exceptions in your crosscuts, don't go trying to fix the exception by modifying state. Either kill the thread, or let the original logic deal with it. Our project was a bit of a laboratory environment. It was a university course that meant to test our ability to apply Patterns of Software Development (i.e. GoF) by having us implement a board game called Bohnanza (basically a heavily simplified Magic: The Gathering). Our approach was to fully focus on implementing the business logic in a correct and test-driven fashion. In the weeks we spent on implementing the business logic we never implemented any GUI. Then when it was done instead of polluting the business logic with the traditional MVC architecture, we designed a GUI that was layered on top of the business logic through AOP. The GUI was just observing through cross cuts the transitions of the games state machine, rendering the relevant game elements and making available the valid inputs. We were one of the few teams who managed to have both a correct game logic and a fully functioning GUI as well as a test suite with good coverage.

FranOntanaya 12y ago

I've found myself wanting at times to keep logging outside the fuction, but then I realized I would have to write a lot of extra comments to fill in for the documentation the logging itself provides. As long as the logging logic itself is kept elsewhere, having logging instructions within the code is not an obstruction. Logging events themselves can have semantic value, as they would often mark some key point in the execution.

dcre 12y ago

Nice writeup, though I was struck by the author's funny use of the word "concerns": > Remember that AOP aims to separate concerns from business logic ... It turns out that nearly half our function code is devoted to concerns! Separation of concerns is about separating concerns from each other, not from business logic. Business logic and logging are both concerns. It doesn't ruin the article or anything, it's just an interesting mistake.

yazaddaruvala 12y ago

I've always wondered why only Java seems to have this concept. I haven't quite dug into a "real" macro system (I don't mean the c macro system) but is it that a good macro system is able to replace("emulate") AOP?