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.
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.
Annotating the Methods seems like an anti-AOP pattern to me. Of the comments become code and get filled with AOP stuff, it's not an different Form putting the calls into the methods themself, beside some performance improvements when running the code without annotations. But the code will be littered with stuff that should be outside of it.
It makes into a slightly different but still invaluable pattern. I'd rather have code that says what it does, but says it in the most concise way possible, than code that just has black magic running on it in the background.
1) Reduce 'soft' duplication. Overhead of having many small logging calls everywhere is probably higher than we all want to admit
2) Reduce small variances. Common logging format is useful (as a baseline-- additional logging is probably also useful)
I'm not terribly familiar with AOP but the cognitive overhead IMO is reduced if you just have to act as a client to logging (via annotation) than bespoke implementations at each call site.
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.
We use AOP at my job for an ASP.NET project (disclaimer: I introduced itt) and it works well for our purposes. We have custom authentication/authorization mechanism and AOP fits the need well. The base class of controllers are annotated with decorators and these rules filter down to all derived classes and action methods. These rules can be overridden at the method level by applying an alternate annotation that overrides the inherited one. This combined with automatic model binding allows us to automatically check access to any resource without performing explicit checks in every method. Security by default is a huge win.
From what I understand, AOP is mainly useful for modifying code at runtime that you can't modify before compile time. So for adding logging to your app, meh. For adding logging around a closed source third party lib? Awesome.
Compile time around third party code, or just yours? Because I was trying to extract a point of difference where AOP does something you couldn't do otherwise.
AFAIK - PostSharp modifies your code based on annotations you specified on whole assemblies, namespaces or just classes during compilation to do stuff that otherwise would be impossible
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.