Timeline for IOC Containers break OOP Principles
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 21, 2014 at 2:22 | comment | added | maple_shaft♦ | Please avoid extended discussions in the comments section. If you would like a further discussion then please visit our chat room. Thank you. | |
| Sep 20, 2014 at 13:36 | comment | added | Suamere | I like this answer the most because it's like giving a pissed off kid a gun and sending him to school, then saying the kid wasn't using the gun right. Obviously there are a lot of flaws with the massive openings IOC Containers give you to perform bad development practices... then covers them up in a pretty facade. However, the truth still stands that whoever it is with the Gun has the responsibility to use it correctly, and their peers/coworkers should be reviewing their use and doing due diligence for best practices. | |
| Sep 19, 2014 at 16:46 | comment | added | Telastyn | @Euphoric - There's no major difference, and I welcome you coming up with an concrete example that shows otherwise. | |
| Sep 19, 2014 at 16:43 | comment | added | Euphoric | @Telastyn First, simplistic examples never describe the whole problem. They are more dangerous than useful. Second, there is major difference between explicit interface and generic Action. If you would change your example to use some programmer-created interface, it would be obvious that the example is wrong. | |
| Sep 19, 2014 at 16:39 | comment | added | Telastyn | @Euphoric - Like I said, it's a simplistic example to boil down the problems with using IoC containers in more realistic and complex scenarios. You do use IoC containers on interfaces with functions, right? | |
| Sep 19, 2014 at 16:38 | comment | added | Euphoric | @Telastyn Your example doesn't make sense, because it is not a case where IoC should be used. It is same as using a tool incorrectly and then complaining the tool is is broken. IoC should be used on much more specific interface than simple Action. | |
| Sep 19, 2014 at 14:17 | comment | added | Ben Aaronson | By the way, I'm also not sure why you're directly associating DI from config files with IoC containers. Most (all?) IoC containers allow you to do all your dependency set up in code. They generally provide tools like modules and conventions to support this. Likewise, it's perfectly common to see factories used for poor man's DI which do resolve types from config. So what you're actually complaining about seems pretty much orthogonal to usage of IoC containers. | |
| Sep 19, 2014 at 13:50 | comment | added | Telastyn | @BenAaronson - In theory, it's not and less a violation. In practice, the code change is much less likely to run into the sort of issues OCP is there to prevent than a configuration change (in a language like C#). It's much easier to test the code change in isolation, and much easier to see the impact of the change. | |
| Sep 19, 2014 at 13:47 | comment | added | Ben Aaronson | @Telastyn Right, I understand that, what I mean is, how is that any less a violation of OCP than changing an IoC container's config? Either way- if you consider config the same as code- you're making a small modification at the top level of your application, right? | |
| Sep 19, 2014 at 13:41 | comment | added | Telastyn | @BenAaronson - I'm not saying to abandon DI, if you want a different concrete dependency, then pass in a different concrete dependency. | |
| Sep 19, 2014 at 13:38 | history | edited | Telastyn | CC BY-SA 3.0 |
Respond to comments asking to elaborate/clarify
|
| Sep 19, 2014 at 13:29 | comment | added | Ben Aaronson | Anyway, the reason to change configuration for an IoC container is generally about changing which concrete dependency gets injected, or some lifecycle management or whatever, right? So if you don't have an IoC container, how would you do that without making a modification to your code? | |
| Sep 19, 2014 at 13:27 | comment | added | Euphoric | @Telastyn Software changes. Requirements change. That is a fact of life. But this change should result, not in changing existing code, but in adding new code. If you implement software according to this, changing software means adding new class in a new assembly, that replaces previously used class. Then you end up with multiple possible implementations, that then can be chosen depending on which behavior you want. Thats what OC princple is all about. And IoC helps you in wiring up all those behaviors into coherent whole. | |
| Sep 19, 2014 at 13:21 | comment | added | Telastyn | @Euphoric - you'll forgive me, but I don't much distinction on changing code vs changing configuration. You're still changing the functionality of your software, invalidating any tests - except now you're doing it in XML and in production directly. In most IoC containers I've worked with, saying "this isn't code because it's in XML" is like saying singletons aren't global variables because they're a pattern. The effect is the same. | |
| Sep 19, 2014 at 13:18 | comment | added | Ben Aaronson | @Telastyn That's not what the open/closed principle says. Otherwise a method that takes parameters would violate OCP because I could "modify" its behaviour by passing it different parameters. Likewise under your version of OCP, it would be in direct conflict with DI, which would make it rather strange that both appear in the SOLID acronym. | |
| Sep 19, 2014 at 13:16 | comment | added | Euphoric | @Telastyn The "closed for modification" means that it should not be necessary to change(modify) the code, to change the behavior of a whole. With any external configuration, you can just point it to a new dll and have the behavior of a whole change. | |
| Sep 19, 2014 at 11:33 | comment | added | Telastyn | @Euphoric - open for extension, closed for modification. If you can change the whole program's behavior, it's not closed for modification, is it? IoC configuration is still your software, it is still code used by your classes to do work - even if it's in XML rather than Java or C# or whatever. | |
| Sep 19, 2014 at 7:20 | comment | added | Euphoric | But IoC is exact opposite to what you said. It employs Open/Closeness of of the program. If you can change whole program's behavior without having to change code itself. | |
| Sep 18, 2014 at 19:39 | comment | added | Suamere | Right. And a lot of shops will claim their product is so complex that they fall into that category, when they really don't. As is the truth with many scenarios. | |
| Sep 18, 2014 at 19:34 | history | answered | Telastyn | CC BY-SA 3.0 |