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.
Comments
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.
It's a little different:
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.