[mkdirp]

> What does dependency injection give you that a simple combination of Singletons, Constructors, and Factories doesn't?

Easy refactoring of an interface/constructor? I've been using go for a while, and I decided to follow the advise of not using a DI for my project. Every time I refactor a constructor, it is a fun hunt to make the same changes everywhere I'm using that constructor.

[bbkane]

Doesn't the compiler tell you exactly what needs to change?

[mkdirp]

It does, but having to go through every single error to fix the issues isn't that easy depending on the number of dependants.

[marvinblum]

Or the IDE. GoLand from JetBrains is very helpful there.

[tadfisher]

That's exactly what a Factory is for; you defer construction and pass around an object that knows how to create an instance. Then you're hunting at the root of your call tree to swap out a Factory instead of throughout your codebase to change a constructor call.

This is also what DI amounts to in practice. Frameworks abstract over it in the name of DRY, but at the same time introduce all the downsides of frameworks.

[mkdirp]

A service still needs its own dependencies, thus forcing you to change its factories where needed. With a DI you re-define it in a single place.

[BobbyJo]

That's true. However, the decoupling that occurs when refactoring one and not the other creates two different code structures, often with different levels of abstraction. I saw the same thing happening with a combination of react and redux, an it made debugging weird behaviors really, really, hard.