Dependency Injection has a fancy name that makes some developers uncomfortable, but it's really just all about making the code easier to test. Basically everything that the class depends upon has to be informed during construction.

This can be done manually, but becomes a chore super fast - and will be a very annoying thing to maintain as soon as you change the constructor of something widely used in your project to accept a new parameter.

Frameworks typically just streamline this process, and offers some flexibility at times - for example, when you happen to have different implementations of the same thing. I find it funny that people rally against those Frameworks so often.

To make things more concrete, let's say you have a method that gets the current date, and has some logic there (for example, it checks if today is EOM to do something). In Java, you could do `Instance.now()` to do this.

This will be a pain in the ass to test, you might need to test, for example a date when there's a DST change, or February 28th in a leap year, etc. With DI you can instead inject an `InstantSource` to your code, and on testing you can just mock the dependency to have a predictable date on each test.

I've written a couple large apps using Uber's FX and it was great. The reason why it worked so well was that it forced me to organize my code in such a way as to make it super easy to test. It also had a few features around startup/shutdown and the concept of "services" and "logging" that are extremely convenient in an app that runs from systemd.

All of the complexity boils down to the fact that you have to remember to register your services before you can use them. If you forget, the stack trace is pretty hard to debug. Given that you're already deep into FX, it becomes pretty natural to remember this.

That said, I'd say that if you don't care about unit tests or you are good enough about always writing code that already takes things in constructors, you probably don't need this.

Another downside of DI is how it breaks code navigation in IDEs. Without DI, I can easily navigate from an instance to where it's constructed, but with DI this becomes detached. This variable implements Foo, but which implementation is it?

The system is composed of classes which are nicely encapsulated, independent and obey Liskov substitution and all that. You can connect them in different arrangements and they play along nicely.

But then some classes which use other classes hard code those classes in their constructor. They then work with those specific hard-coded classes. It's like if someone crazy-glued some of our Lego blocks together.

We recognize this problem and allow the sister objects to be configurable.

Then some opinionated nubmnut comes along and says, "hey, we should call this simple correction 'dependency injection'". And somehow, everyone listens.

Strangely I seem to have built all of my software without dependency injection. I must be a terrible programmer.

Every so often a developer challenges the status quo.

Why should we do it like this, why is the D in SOLID so important when it causes pain?

This is lack of experience showing.

DI is absolutely not needed for small projects, but once you start building out larger projects the reason quickly becomes apparent.

Containers...

- Create proxies wrapping the objects, if you don't centralise construction management it becomes difficult.

- Cross cutting concerns will be missed and need to be wired everywhere manually.

- Manage objects life cycles, not just construction

It also ensures you code to the interface. Concrete classes are bad, just watch what happens when a team mate decides they want to change your implementation to suit their own use cases, rather than a new implementation of the interface. Multiply that by 10x when in a stack.

Once you realise the DI pain is for managing this (and not just allowing you to swap implementation, as is often the the poster boy), automating areas prone to manual bugs, and enforcing good practices, the reasons for using it should hopefully be obvious. :)

DI is a very religious concept, people hate it or love it.

I myself am on the dislike camp, I have found that mocking modules (like you can with NodeJS testing frameworks) for tests gives most of the benefits with way less development hell. However you do need to be careful with the module boundaries (basically structure them as you would with DI) otherwise you can end up with a very messy testing system.

The value of DI is also directly proportional to the size of the service being tested, DI went into decline as things became more micro-servicy with network-enforced module boundaries. People are just mocking external services in these kind of codebases instead of internal modules, which makes the boundaries easier.

I can see strict DI still being useful in large monolith codebases worked by a lot of hands, if only to force people to structure their modules properly.

It always blew my mind that "dependency injection" is this big brouhaha and warrants making frameworks, when dynamic vars in Lisp basically accomplish the same task without any fanfare or glory.

Love this article, Spring is a cancer in Java, its one of the reasons the language isn't fashionable.

As a (mainly) Python dev, I'm aware that there are DI frameworks out there, but personally I haven't to date used any of them.

My favourite little hack for simple framework-less DI in Python these days looks something like this:

    # The code that we want to call
    def do_foo(sleep_func = None):
        _sleep_func = sleep_func if sleep_func is not None else time.sleep

        for _ in range(10):
            _sleep_func(1)

    # Calling it in non-test code
    # (we want it to actually take 10 seconds to run)
    def main():
        do_foo()

    # Calling it in test code
    # (we want it to take mere milliseconds to run, but nevertheless we
    # want to test that it sleeps 10 times!)
    def test_do_foo():
        mock_sleep_func = MagicMock()
        do_foo(sleep_func=mock_sleep_func)
        assert mock_sleep_func.call_count == 10

Mark Seemann has written extensively about the subject.

He a tremendous source of knowledge in that regard.

https://blog.ploeh.dk/2017/01/27/from-dependency-injection-t...

I highly agree. I especially believe that manual DI should always be the starting point. Eventually one can evaluate if there really is a need for a framework. It's already dangerous if I have to change the code significantly just to satisfy the framework.

You probably don't need functional programming. Here is how to do it with a for-loop.

You don't see many articles written like that because it kinda would be obvious that the author hasn't bothered to understand the approach that he is critizing.

Yet when it comes to OO concepts people from "superior" platforms like Go or the FP crowd just cannot let go of airing their ignorance.

Just leave OO alone unless you are genuinely interested in the approach.

DI is fine, if it is fully typed, and objects are explicitly initiated by the user, and the DI only does thread-safe dependency resolution.

> But that reflection-driven magic is also where the pain starts. As your graph grows, it gets harder to tell which constructor feeds which one. Some constructor take one parameter, some take three. There’s no single place you can glance at to understand the wiring. It’s all figured out inside the container at runtime.

That's the whole point. Depdendency Inversions allows you to write part of the code in separation, without worrying about all the dependencies of each component you create and what creates what where.

If your code is small enough that you can keep all the dependencies in your head at the same time and it doesn't slow you down much to pass them all around all the time - DI isn't worth it.

If it becomes an issue - DI starts to shine. There are other solutions as well, obviously (mostly in the form of Object-Orientified global variables - for example you keep everything in GameWorld object and pass it everywhere).

Common sense is in short supply these days. It's a shame we need blog posts like these to outline how much you lose when you go with the "magic" approach. Devs just seem to be allergic to simple but verbose code.

I agree. I had to do what the article says in Node for a project for $reasons but secretly I loved not using a framework, and having the construction explicit. I've also seen bugs because tests may set up DI different to prod.

Looking forward to someone writing the Spring equivalent this on the JVM

Language and/or library issue. DI helps code be easier to follow, more decoupled and read with less boilerplate AND helps testing much easier.

If you are on node/ts look at effect-ts.

One thing that can motivate a dependency container is a complex chain of constructors.

IoC is nice (or DI as a concept in particular), but DI frameworks/libraries sometimes are a mess.

I've had my fair share of Java and Spring Boot projects and it breaks in all sorts of stupid ways there, even things like the same exact code and runtime environment working in a container that's built locally, but not working when the "same" container is built on a CI server: https://blog.kronis.dev/blog/it-works-on-my-docker

Literally a case where Spring Boot DI just throws a hissy fit that you cannot easily track down, where I had to mess around with the @Lazy annotation (despite the configuration to permit that being explicitly turned on too) in over 100 places to resolve the issue, plus then when you try to inject a list of all classes that implement an interface with @Lazy it doesn't seem like their order is guaranteed either so your DefaultValidator needs to be tacked on to that list manually at the end.

Sorry about the Java/Spring rant.

It very much feels like the proper place for most DI is at compile time (like Dagger does for Java, seems closer to wire) not at runtime, or just keep IoC without a DI framework/library and having your code look a bit more like this:

  @Override
  public void run(final BackendConfiguration configuration,
                  final Environment environment) throws IOException, TimeoutException {
      // Initialize our data stores
      mariaDBManager = new MariaDBManager(configuration, environment);
      redisManager = new RedisManager(configuration);
      rabbitMQManager = new RabbitMQManager(configuration);
      
      // Initialize our generic services
      keyValueService = new KeyValueService(redisManager);
      sessionService = new SessionService(keyValueService, configuration);
      queueService = new QueueService(rabbitMQManager);
  
      // Initialize services needed by resources
      accountService = new AccountService(mariaDBManager);
      accountBalanceService = new AccountBalanceService(mariaDBManager);
      auctionService = new AuctionService(mariaDBManager);
      auctionLotService = new AuctionLotService(mariaDBManager);
      auctionLotBidService = new AuctionLotBidService(mariaDBManager);
      
      // Initialize background processes based on feature configuration
      if (configuration.getApplicationConfiguration().getFeaturesConfiguration().isProcessBids()) {
          bidListener = new BidListener(queueService, auctionLotBidService, auctionLotService, accountBalanceService);
          try {
              bidListener.start();
              logger.info("BidListener started");
          } catch (IOException e) {
              logger.error("Error starting BidListener: {}", e.getMessage(), e);
          }
      }
  
      // Register resources based on feature configuration
      if (configuration.getApplicationConfiguration().getFeaturesConfiguration().isAccounts()) {
          environment.jersey().register(new AccountResource(accountService, accountBalanceService, sessionService, configuration));
      }
      if (configuration.getApplicationConfiguration().getFeaturesConfiguration().isBids()) {
          environment.jersey().register(new AuctionResource(
              auctionService, auctionLotService, auctionLotBidService, sessionService, queueService));
      }
      ...
  }

Overall, I agree with the article, even across multiple languages.

DI frameworks add confusion and require more unnecessary memory in advance

Don't hate a paradigm because you only experienced one bad implementation of it.

In IntelliJ, with the Spring Framework, you can have thorough tooling: You can inspect beans, their dependencies, you even get a visual bean graph, you can write mocks and test dependencies and don't even need interfaces anymore and if a dependency is missing, you will receive an IDE warning before runtime.

I do not understand why people are so excited about a language and its frameworks where the wheel is still actively being reinvented in a worse way.