9

I've been looking into using the Typhoon framework for dependency injection this week. I get that separating the construction of objects is beneficial for replacing arbitrary components with mocks during unit testing, and so far I have seen benefits from this alone.

But I cannot help but think that where before I had a humongous view controller class that had tens of header imports, I now have a humongous factory class that has tens of header imports. Am I supposed to avoid having a massive factory class?

7
  • 6
    In a decade I expect DI take over the bashing list from Singleton, but this time for good reasons. It have some good uses but I suggest to be very careful evaluating the impact.
    – Balog Pal
    Jun 7 '13 at 11:25
  • 5
    I do not think that dependency injection is a way to reduce complexity but a way to avoid implicit dependencies (use of global symbols / free variables) in favour of explicit dependencies (use explicit parameters / bound variables). So, the complexity is still there, but you are forced to deal with it because you make it explicit in your method / constructor signatures.
    – Giorgio
    Jun 7 '13 at 11:29
  • 7
    Note that pretty much any system for organizing code could be described as "just moving the complexity somewhere else". It is not about removing complexity so much as organizing it in the most logical, useful way.
    – user82096
    Jun 7 '13 at 11:40
  • 1
    If you have to import 50 headers, you have to do it somewhere. DI helps you with easier way of unit testing your code. Jun 7 '13 at 11:46
  • 2
    So, are you saying that now your controller is focussed on controlling and your header import factory is focussed on header imports? How can that ever be a bad thing, whether you're using a DI framework or not?
    – pdr
    Jun 7 '13 at 11:47
16

Dependency Injection simply helps define how one object knows about another dependent object. It is not going to help you reduce the overall complexity of the system. If you needed tens of import before DI, you will still need tens of imports after. The difference is that these imports will be in a location (class) that makes more sense (factory, builder, etc).

By allowing dependencies to be provided through a constructor or method you allow yourself the flexibility to supply a different, yet still valid, dependent object to your class and increase cohesion of said class by removing concerns.

There are several principles that are similar and are often used together: Dependency Injection (DI), Inversion of Control (IoC), and the Dependency Inversion Principle (DIP)

From this article http://martinfowler.com/articles/dipInTheWild.html

DI is about wiring, IoC is about direction, and DIP is about shape

2
  • 2
    +1, for the last quote. It's the best clarification of these 3 concepts that people often misunderstand.
    – haylem
    Jun 7 '13 at 13:20
  • The linked article above is really outstanding. A sufficiently deep and very clear explanation. Sep 12 '13 at 19:38
10

Dependency injection does not reduce complexity, but it increases manitainability through separation of concerns and reduced coupling.

But I cannot help but think that where before I had a humongous view controller class that had tens of header imports, I now have a humongous factory class that has tens of header imports. Am I supposed to avoid having a massive factory class?

You're supposed to avoid "humongous" classes, period. So let's say you split up the view controller into smaller, more maintainable classes. Now all of them are responsible to get hold of their dependencies. DI helps you to move this dependency management from all of those classes into a factory/configuration class which is only responsible for dependency management - see Single Responsibility Principle. And while it will certainly be much less "humongous" than the original view controller, if it gets too big you always have the option to split it into smaller dependency-management classes that are responsible for different parts of the application.

2

In layman's words:

Dependency injection moves complexity to where it does less harm.

EDIT for @gnat: DI is not just moving complexity to a separate class, it's moving it to where it causes the less harm.

2
  • how does this answer the question asked?
    – gnat
    Sep 12 '13 at 13:36
  • @gnat added an edit, my answer explains in my opinion how is DI not just moving complexity into a separate class. Sep 12 '13 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.