[lastangryman]

Ah this takes me back to my first job. Medical start up, working on a very long term project that the company was completely unequipped to deliver. I was young and keen so didn't appreciate the context, I just did stuff.

For some reason, we hired an "architect" from a large Bank that used Java. He used to make proclamations like "we should write tests", but never actually got into more detail than that. One of his preachings was about aspect oriented programming and how it was going to be future. He did a talk on it, and I remember someone asking "what else does it apply to apart from logging and Auth?"...no answer.

Not long after, I left. 2 years there, probably over 15 engineers, I don't think we built anything close to a functioning software product.

[retrocryptid]

It's also good for teasing out functionality for complex legacy code. We used AOP tools to construct a call graph in the spaghetti section of the codebase. It was then used to figure out what we had to refactor.

Worth thinking about if, like our app, it's crazy spaghetti and call graph is based on runtime state (which makes static analyzers less useful.)

[rjbwork]

Caching, managing object life times in IOC containers, input validation, are some common uses I've seen.

[speed_spread]

Transaction coordination, Error management (retry, backoff, fallback).

In the end, aspects were always used for the same transversal concerns, which any serious framework would provide explicit support for anyway.

Going beyond these to use aspects for application domain modeling is popping open an immense can of carnivorous worms on the dev team.

[lastangryman]

Thanks - I'm sure there are other uses cases, I didn't mean to imply there weren't, just for me I always associate AOP with a time in my career where nothing useful was ever shipped, but there was lots of pontificating and philosophising about rather abstract things like this.

[retrocryptid]

Lol. I associate C++ with that. Turns out the first big C++ project I was involved with had a lot of research types. To their credit, when they did something it was almost always the best thing to do. But there was A LOT of thought and discussion put into each line of code.

For a decade I thought about C++ as being "the language for people who are forced to think long and hard about every line of code."

And then I saw "normal" C++ code everyone else was writing...

I now sort of like it (C++), especially after recent language additions.

[whoisthemachine]

It seems to me a lot of these things are handled more plainly by delegation and composition.

[_the_inflator]

I have also been there. I remember it vividly when using the ZEND framework in PHP. It is a fad, in my opinion.

Also architects doing their stuff: they for sure know best how to couple boxes in a PowerPoint presentation. ;)