4 ms·

I've seen the classic examples of AOP being used to log or authorize, but you can easily do that without "cluttering your code" by using the decorator pattern?

• rjbwork 3y ago
  Decorators are one implementation of how to do some kinds of AOP afaik? If you look at a system like PostSharp or AspectJ, they do it via attributes which modify the way in which a method is invoked, or even if it is invoked by the system. There are other ways to use those systems, by programmatically targeting parts of code to modify via reflection, but that is the simplest and most common.
  • toolslive 3y ago
    You start with reification of some part of your system/codebase. Once you have that, it's easy to adapt things. For example, in an OO context, once you've objectified your method call instance into an object that has reference to the caller, callee, parameters and the code to execute it's easy to log it, decide if the caller needs to be authorized aso... The are some other considerations like when (compilation time, run time, ...) It's a really interesting code organization strategy and the only problem I've experienced with it is that (for example decorators) introduce a static layering (the order of the decorators) that works against the inter-aspect dynamics. For example, a call only needs to be logged if there is a necessity of authentication in a distributed context. In essence, you might not be able to have a static ordering that works for use cases. (security on top, or on the bottom ?)
• jillesvangurp 3y ago
  Which would be a form of AOP that mostly emerged after the AOP hype of the late nineties. I was looking at things like aspect oriented programming and subject oriented programming around 1999-2000 time frame as part of my phh d thesis work. There were a few interesting derivatives. The main aspectj work sort of folded into the spring framework which still uses some parts of that as part of the annotation processing in e.g. hibernate. That's the main reason, it bundles byte code manipulation libraries. So it can weave in some aspects. But most of the aspectj language level features never really became a mainstream thing. Decorators, annotations, and similar language constructs emerged as a good enough thing that did most of what AOP was trying to accomplish. Python added those around 2003. Java gained annotations with Java 1.5 which was a few years after that. Other languages use macros or similar features to achieve the same thing. Mostly good enough though IMHO people over use them. BTW. if you are into functional programming, this should feel really wrong. Basically you are deliberately adding side effects to your code by saying around or before/after a call to this, also do that. Of course the goto functional programming solution of monads has its own issues in terms of complexity, philosophical debates, and people having a hard time understanding them. The researchers in Utrecht where I studied in the mid nineties were into monads big time. My compiler course was basically about the compiler generator technology they were working on. Monads top to bottom. I liked aspectj a lot better after that. Easier to grasp for my primitive brain.
  • asplake 3y ago
    > BTW. if you are into functional programming, this should feel really wrong. Basically you are deliberately adding side effects to your code by saying around or before/after a call to this, also do that. A decorator in Python (and I guess other languages) is a nothing but a function of a function. And you’re taking those side effects out of your function. What’s not to like?
    • jillesvangurp 3y ago
      You are confusing the implementation and the syntax. It's a special syntactical construct (an annotation) that gets translated into function calls that amount to doing AOP type things around the call to the original function. That's more or less how annotations work in other languages too. Some do it with reflection, some do it at compile time, etc. The goal is the same: get rid of the drudgery of spelling out the function call in order to introduce the side effect in the form of a thing that gets called before/after/around another thing. Not against that btw. and I always appreciated how pragmatic python can be with a lot of things.
      • deleted 3y ago
        [deleted]
    • lmm 3y ago
      > A decorator in Python (and I guess other languages) is a nothing but a function of a function. And you’re taking those side effects out of your function. What’s not to like? A Python decorator may be "just a function", but in order to do anything useful it generally has to do some kind of nasty hack - mutable state, global state, monkeypatching or the like - because the meat of what a decorator does usually lies in what happens when you call a decorated function, not in when you define it.
• snarfy 3y ago
  I created an AOP library for .net core. It uses the decorator pattern. Aspects are attributes you apply to classes and methods. It was fun to implement. It was all the rage in game programming. I never used it myself. As all of the other comments have mentioned, it ends up being a kind of anti-pattern. Nobody wants logic strewn about your code base. It might as well be called side-effect based programming.