5 ms·

Can you explain the IOC hell? isn't most IOC / Dependency Injection patterns suppose to help the software maintainability ?

jrumbut 7y ago
I tend to think of these more as enabling modularity and convention-over-configuration (being Rails-y if you will) rather than maintainability. Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code. One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files. That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).
lugg 7y ago
Yes, they are supposed to. The problem is that it gets taken to extremes when it's done at the framework level. The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around. Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful. If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting. IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem. The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC. Within modules usual namespacing and new constructors were used liberally.

jrumbut 7y ago

I tend to think of these more as enabling modularity and convention-over-configuration (being Rails-y if you will) rather than maintainability. Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code. One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files. That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).

lugg 7y ago

Yes, they are supposed to. The problem is that it gets taken to extremes when it's done at the framework level. The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around. Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful. If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting. IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem. The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC. Within modules usual namespacing and new constructors were used liberally.