4 ms·
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 modi
by 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 agoYou 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 ?)