Timeline for IOC Containers break OOP Principles
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 10, 2017 at 1:39 | comment | added | ipavlu | I really do not get the logic of explanation that something is not bad based on the fact, that it is a framework. ServiceLocators are made as frameworks too and they are deemed as bad:). | |
| Oct 9, 2014 at 23:58 | audit | First posts | |||
| Oct 10, 2014 at 0:03 | |||||
| Sep 23, 2014 at 8:47 | comment | added | Den | "Dependency Inversion - IoC containers let you do dependency inversion easily" - they don't, they are simply leveraging something that is beneficial whether you have IoC or not. Same with other principles. | |
| Sep 19, 2014 at 14:07 | comment | added | Ben Aaronson | @Doval I don't see how it's injecting code into a class. Note I'm talking about Castle DynamicProxy style, where you have an interceptor, rather than the IL-weaving style. But an interceptor is essentially just a decorator that uses some reflection so that it doesn't have to couple itself to a particular interface. | |
| Sep 19, 2014 at 14:03 | comment | added | Doval | @BenAaronson Considering that AOP injects code into a class, I wouldn't call it more OCP-friendly. You're forcefully opening and changing a class at compile/runtime. | |
| Sep 19, 2014 at 4:51 | comment | added | Ben Aaronson | Excellent answer. Additionally, I think all the major IOC containers also support AOP, which can help a lot with OCP. For cross-cutting concerns, AOP is usually a more OCP-friendly route than a Decorator. | |
| Sep 19, 2014 at 4:28 | history | answered | Matthew | CC BY-SA 3.0 |