16

Recently I did a presentation on Dependency Injection and IoC (Inversion of Control) containers. I also was talking about SOLID principles. I think without SOLID, DI Containers make no sense.

I was focusing on few arguments.

  1. Maintainability
  2. Scalability
  3. Testability

However I was a bit disappointed when the tech group replied that they don't see a point in doing DI with Containers and so on

I admit that the presentation may not be perfect and the message did not get across.

Can anybody advise me how to convince an audience that Dependency Injection is a good thing. How to convince them to change their mindset about loose coupled classes & components (We've debated a bit around that too)

What would be a "killer" argument for DI ?

Chase Florell
  • 46,378
  • 57
  • 186
  • 376
Dorin
  • 524
  • 3
  • 12
  • 2
    There is no such "killer argument": it's a religious belief, in a sense that one cannot "prove" it any better than a thesis about "Language X being better than language Y". The best thing you can do is proving that DI is good for a particular purpose, such as ensuring testability of your system. – Sergey Kalinichenko Aug 31 '13 at 12:09
  • the thing is that Testability alone is not a strong argument. I came across with similar situations and the reply was that it takes too much time to do unit/system tests. so I failed again – Dorin Aug 31 '13 at 12:56
  • This question might be better suited to http://programmers.stackexchange.com/. – Bob Horn Aug 31 '13 at 13:33
  • 22
    This is a bad fit for SO. There is no killer argument for DI because DI is basically a bad idea. The idea of DI is that you take what ought to be implementation details of a class and then allow *the user of the class* to determine those implementation details. This means that the author of the class no longer has control over the *correctness* or *performance* or *reliability* of the class; that control is put into the hands of the caller, who does not know enough about the internal implementation details of the class to make a good choice. – Eric Lippert Aug 31 '13 at 14:31
  • 24
    @EricLippert: It's unfortunate that someone in your position takes this standpoint. Your standpoint clearly comes from writing reusable libraries or even compilers, not from writing LOB applications. For reusable libraries, other rules hold. There has been written a lot here at stackoverflow about the use and importance of dependencies injection here at stackoverflow. Have you ever considered reading Mark Seemann's book Dependency Injection in .NET? You really should. – Steven Aug 31 '13 at 14:54
  • 24
    @EricLippert Saying that DI is basically a bad idea lacks as much nuance as saying that classes should *always* be sealed, etc. Ultimately, it's a balance. True, the disadvantages of DI that you mention are, to an extent, real. However, they are exactly the same as the disadvantages of inheritance. If we accept the argument that both inheritance and DI is a bad idea, then there's no longer any polymorphism. Then OOP goes out the window. FP does, too, because FP is based on the compositionality of functions (also polymorphism). Is there anything else than Procedural Programming left, then? – Mark Seemann Aug 31 '13 at 15:10
  • 12
    @MarkSeemann: This is not a good forum to carry on a discussion, so perhaps I oughtn't to have responded to the original post provocatively. I agree that my 500 character comment utterly lacks nuance. Basically, my argument is that low *reliability* is a bigger problem than low *configurability*. (And I *have* made the argument that 99% of classes should be sealed and that sealed should be the default; I am not a huge fan of reuse through inheritance. I'll do it, but experience shows that it's not the panacea that OOP true believers seem to think it is.) – Eric Lippert Aug 31 '13 at 15:25
  • I'd love to see this conversation pickup in Chat. – Chase Florell Aug 31 '13 at 15:33
  • 5
    @EricLippert I think the primary argument in favor of DI is decoupling, not for configurability but for testability. In that sense DI increases reliability precisely by allowing you to easily construct test cases without having to account for the entire dependency graph. – tvanfosson Aug 31 '13 at 15:38
  • While you don't need to use a DI framework (it will make it easier), I think you're on the right track. The argument that I would make is that testing increases quality and safety, reducing rework and easing the ability to add features, these in turn increase speed - more than enough to offset writing tests. An added benefit to testing - assuming you do it first - is that you get to think about and discover the solution before writing the implementation. It is important to get the right level of testing and to treat your test code as a first class citizen wrt design/refactoring. – tvanfosson Aug 31 '13 at 15:47
  • 3
    @EricLippert We could continue the discussion over on Bryan J. Ross' blog: http://rossipedia.com/blog/2013/08/dependency-injection-considered-harmful/ – Mark Seemann Aug 31 '13 at 17:08

0 Answers0