A quick rant about dependency injection.

I see far too often in projects, a huge over-reliance on dependency injection / IOC frameworks which permeate throughout the entire codebase.

I cringe every time I see a constructor annotated with @Inject and 10 params.

The benefit of these frameworks is how easy they make it to manage many dependencies. What I dislike about them, is exactly that. I feel that they make it TOO easy to manage many dependencies.

How trivial is it to simply add another constructor param? exactly. And people then wonder why their dependency tree looks insane.

I am a strong believer in injecting dependencies the traditional way, via the constructor with no fancy framework. The reason being that it forces you to think more about the dependencies you are adding to your classes, and consider if they are really all needed.

The other problem I have with it, is it basically encourages you to inject everything because its so easy. The purpose of dependency injection is inversion of control and allowing classes to depend on abstraction rather than concrete implementation. All that goes out the window when you @Inject 6 different concrete classes.

Use dependency injection for its intended purpose, not as an excuse to be lazy and avoid thinking about dependencies.

  • 1
    I would say that the problem is not with the framework but with the people using it. We all know the expression "When you have a hammer all problems start looking like nails. This seems to be the root of your complaint here.

    The answer to this issue is not to take away the hammer, but to teach people to look for other more appropriate tools for the job at hand.
  • 0
    In a way, with DI and IoC containers we're going to do the same crap as we did with inheritance, abusing.
    We're ending up with the same situation and same problem we were trying to solve, coupled stuff that over time becomes untouchable.

    I personally support messaging approach to its maximum possible extent, pub/sub if you prefer. Every injected stuff, or every class you may inherit from, can be represented as a separate aspect, and more important, is not your freaking business how and if it does whatever it does.
    "Go thru a message bus and keep things decoupled" my motto.

    Not that the global dependency tree decrease in size, but at least the codebase gets manageable.
  • 2
    @SnafuAI 100% agree.
    There is a time and a place for IOC containers and DI frameworks. I just dont think that place is “scattered throughout the business logic of your app”
Add Comment