3 ms·

I don't see this. Designing for dependency injection is mostly about passing objects around as a parameters instead of using globals / singletons. It's in big

I don't see this. Designing for dependency injection is mostly about passing objects around as a parameters instead of using globals / singletons. It's in big code bases where the tempatation to use a singleton is greatest, because no one wants to refactor all the function signatures to add the extra parameter.

taeric 10y ago
Making every part of your system an injected thing can lead to massive configuration points where there is only one possible choice for much of what is configured. That is annoying and I fail to see how it really helps extensibility. Oddly, I think the problem is often lack of a global namespace. Consider how you pull in the "parseFoo" method. In languages with a global namespace, you just use it. You can put a declaration saying the method has to exist, but no need to import it from anywhere. That is a build time concern, not a write time one. Even better, changing the implementation does not require changing the user site, at all. Namespaced languages have to use factories and abstract factories to get the same flexibility. (Or dependency injection.) I don't even think they're bad ideas, just find it interesting how much effort it takes to change which method I'm actually calling.
- adrianratnapala 10y ago
  I agree with you about fractories often being stupid replacements for free-functions. I am thinking of more dynamic things: e.g. a handle to a network connection should be passed around instead of singletoned. But even if dependency injection has all the costs you claim for it. Those costs are at their smallest when the system is small. So I still say xypud is wrong: you should do injection by default and when it gets too cumbersome then you think about how to streamline the interfaces.
  - taeric 10y ago
    To be honest...I have not thought hard on this. I expected my post to get down voted, as I figured i was taking a frowned upon view. To be more fair, I suspect I am wrong. In practice, I agree with your point. I'd rather do some small costs up front. I'm curious to explore the designs more. I think in systems where you have independent programs working together, a lot of this solves itself. The trend today is to make things one big program. (Not a new trend.)

taeric 10y ago

Making every part of your system an injected thing can lead to massive configuration points where there is only one possible choice for much of what is configured. That is annoying and I fail to see how it really helps extensibility. Oddly, I think the problem is often lack of a global namespace. Consider how you pull in the "parseFoo" method. In languages with a global namespace, you just use it. You can put a declaration saying the method has to exist, but no need to import it from anywhere. That is a build time concern, not a write time one. Even better, changing the implementation does not require changing the user site, at all. Namespaced languages have to use factories and abstract factories to get the same flexibility. (Or dependency injection.) I don't even think they're bad ideas, just find it interesting how much effort it takes to change which method I'm actually calling.

adrianratnapala 10y ago
I agree with you about fractories often being stupid replacements for free-functions. I am thinking of more dynamic things: e.g. a handle to a network connection should be passed around instead of singletoned. But even if dependency injection has all the costs you claim for it. Those costs are at their smallest when the system is small. So I still say xypud is wrong: you should do injection by default and when it gets too cumbersome then you think about how to streamline the interfaces.
- taeric 10y ago
  To be honest...I have not thought hard on this. I expected my post to get down voted, as I figured i was taking a frowned upon view. To be more fair, I suspect I am wrong. In practice, I agree with your point. I'd rather do some small costs up front. I'm curious to explore the designs more. I think in systems where you have independent programs working together, a lot of this solves itself. The trend today is to make things one big program. (Not a new trend.)