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?

Victor
  • 947
  • 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 07 '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 07 '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. –  Jun 07 '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. – BЈовић Jun 07 '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 07 '13 at 11:47
  • @dan1111 I'm just used to concepts like DRY or "smaller classes/methods" where I think it's fair to claim putting them into practice does reduce complexity. Organizing it makes sense also, but was not something I've been actively trying to do. – Victor Jun 07 '13 at 13:00
  • There is no silver bullet to reduce complexity except for actually solving the problem in a simpler way. Every design pattern just answers the question where you do stuff. To reduce complexity, you need to reduce the amount of stuff you need to do to get the job done. – Philipp Sep 12 '13 at 12:14

3 Answers3

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

Seth M.
  • 401
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.

Michael Borgwardt
  • 51,207
1

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.

Tulains Córdova
  • 39,449