AOP is an idea that sounds wonderful as a concept - "Hey wouldn't you love not to be peppering your code with logic unrelated to the business logic in your code?"
Great idea...however, every implementation I have seen is terrible. It makes code nearly impossible to test and audit and, in addition, creates a whole other set of code that needs to be tested and audited.
Taking the example at hand. From the first function I have a clear idea of what to expect, when I should see logging
and what the failure cases and responses are.
Now instead of a 1 line log statement, the article proposes the 7 line meld definition is much cleaner. Where does this code live?
Another 7 lines to track the length of the call, opposed to 3 lines in the function. And now I have a hidden entry to my function - before the calling path was clear...calling dial() meant I called dial() now calling dial() means I actually call some random function which, assuming it has been written correctly, calls dial()
The error handling is possibly the one redemption here, but still - OO provides you with the tools to encapsulate retry logic just fine without resorting to AOP.
I didn't like AOP when I first came across it at University, I didn't like it when I came across some code at a previous employer, and I don't like it now.
No, fortunately. AOP was relegated to the museum of programming history, section 'ideas that didn't work out' (the largest section in the museum, BTW).
I didn't like AOP when I first came across it at University, I didn't like it when I came across some code at a previous employer, and I don't like it now.
I guess a few people are still talking about it because it sounds significant, the name sounds as if it's competing with OOP, instead of being the gimmick that it is.
We do the same thing in OOP (without the "spooky action from distance" you've noticed) with the Decorator & Strategy patterns, very simple patterns, even those who don't know about patterns are probably using them without knowing.
There are people, who prefer pure C, without OOP's "spooky action from distance". Just like language support for OOP concepts, AOP gives you a higher level of abstraction to solve complex problems.
Comments
urggh...is this still a thing?
AOP is an idea that sounds wonderful as a concept - "Hey wouldn't you love not to be peppering your code with logic unrelated to the business logic in your code?"
Great idea...however, every implementation I have seen is terrible. It makes code nearly impossible to test and audit and, in addition, creates a whole other set of code that needs to be tested and audited.
Taking the example at hand. From the first function I have a clear idea of what to expect, when I should see logging and what the failure cases and responses are.
Now instead of a 1 line log statement, the article proposes the 7 line meld definition is much cleaner. Where does this code live?
Another 7 lines to track the length of the call, opposed to 3 lines in the function. And now I have a hidden entry to my function - before the calling path was clear...calling dial() meant I called dial() now calling dial() means I actually call some random function which, assuming it has been written correctly, calls dial()
The error handling is possibly the one redemption here, but still - OO provides you with the tools to encapsulate retry logic just fine without resorting to AOP.
I didn't like AOP when I first came across it at University, I didn't like it when I came across some code at a previous employer, and I don't like it now.
Nice write up though.
No, fortunately. AOP was relegated to the museum of programming history, section 'ideas that didn't work out' (the largest section in the museum, BTW).
Amen.
I guess a few people are still talking about it because it sounds significant, the name sounds as if it's competing with OOP, instead of being the gimmick that it is.
We do the same thing in OOP (without the "spooky action from distance" you've noticed) with the Decorator & Strategy patterns, very simple patterns, even those who don't know about patterns are probably using them without knowing.
There are people, who prefer pure C, without OOP's "spooky action from distance". Just like language support for OOP concepts, AOP gives you a higher level of abstraction to solve complex problems.