5 ms·

The real downside of over-engineering is that time expenditure is non-refundable. If you build a lightweight v1, you still have the option to invest additional

• tigershark 10y ago
  Nope, for example if an application is designed without dependency injection because it is more "lightweight" it is a pain to introduce it later. If you designed it from the start to have clear dependencies and with an IOC container then you'll have a much easier time in changing it when there are new requirements. As you can see the boundary between good engineering and over engineering is pretty thin. And it obviously depends from the context. In a toy application probably you can survive without a container. In a real world project you are going to kill yourself without it (been there, seen that).
  • xupybd 10y ago
    Yes but dependency injection only makes sense at a certain scale. I've yet to see it provide more than it cost.
    • tigershark 10y ago
      When it is done properly it has practically no costs and only benefits. If you start using the container in more than one place, introducing a ServiceLocator pattern, using providers instead of automatic factories then you will pay an high cost. But in these cases you are doing it wrong. Doing it properly it helps you to design the whole application correctly and adds flexibility and modularity for free. As I said, while on a toy project it is a negligible advantage, in a real world project it is an invaluable plus.
      • sbov 10y ago
        Nothing is free.
    • adrianratnapala 10y ago
      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.)
  • revelation 10y ago
    Well you correctly diagnose the biggest problem with DI: it's all or nothing. Only nowadays all usually includes significant 3rd party library code and everybody is stuck trying to figure out how to get their DI magic in place when said 3rd party code doesn't cooperate.