Dependency injection frameworks add confusion

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 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.

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. :)

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

He a tremendous source of knowledge in that regard.

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

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).

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

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.

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.

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.