KickAssCommerce
Is AOP a bad thing?
So this one is a question. I don't know enough about AOP from a practical sense but is it a bad thing?
Does it mean we don't know how to build a "nice" system and so have to add in a hack to let people work with it? Or does it mean we are super cool and flexible?
So the reason I wanted to use AOP is I believe in real world projects any classes in/output, at some point, will need to changed. For every method we write the universe makes a client out there with a feature requests that changes it.
So you could use DI, extend the old class, and rewrite whatever you need to rewrite but for me extending classes or replacing them feels like over engineering. Why not make a small class with some annotation, wrap it before, after, around or whatever, change what you need and do this without the rest of the classes having to know about it.
The downside is the 'magic' that happens, It's hard to figure out who's rewriting what, so a tool for that would be handy. But the benefits of lightweight, conflict free augmentation of existing code outweighs that in my opinion.
AOP is a bad design decision. I don't like interceptors in Magento 2 either (I don't use word plugin here for a reason, as it is not a plugin). If you design SOLID application, your system must follow the Open Closed Principle.
Also, inheritance is a bad decision in majority of the cases as well. Making your code composite has far more benefits and forces you to write architecture that is extensible without actually using "extends".
If you have to extend from a class in order to change the behavior it is a code smell, so your exposed extension points must always have an interface, so anyone can replace implementation without extending from your implementation. It also means you should never use new operator directly, in favor of factories, so at any point of time your concrete class can become an interface.
Hope this one will help you to make the right decision.
I would not call AOP bad per se, as with any programming practice one needs to know where it is applicable and most importantly where not. Given that we are talking about PHP, in this specific case I would not try to rely on AOP because it will bring lots of code generation with it.
AOP will not work with final classes as the generated code needs to extend the userland classes otherwise you are not able in "replace" the userland classes with the generated code.
The more I play around with it and some research I don't think AOP is the right choice for our framework.
