i'm having such a hard time understanding why depe...

# random

[Hullaballoonatic]

i'm having such a hard time understanding why dependency injection is a thing that needs to exist...

[dalexander]

So based on my experience, I think DI is a useful pattern, but DI frameworks are often over-used. I would avoid using DI frameworks until you’re doing so much DI that it’s starting to feel burdensome, because the frameworks tend to add a lot of complexity.
I’ve worked both on projects where the amount of DI was very high and there was no framework, and on projects where there was little need for DI but a framework was in place. Neither situation is pleasant!

[Hullaballoonatic]

It sounds like a germane example of the misuse of OOP sometimes.

[dalexander]

Could be. I think part of the problem is there are a lot of people making blog posts about doing DI, and how it solves their problems. And other people see those posts, but don’t have those problems, and end up implementing it anyway. Sometimes it feels like this development anti-pattern could be applied to almost everything.

[Hullaballoonatic]

you're right!

[Hullaballoonatic]

it's a problem of not understanding the fundamentals.

[tddmonkey]

I’ve shared the same opinion for a long time, and eschew the use of any DI framework tool for my projects. I’ve managed to successfully convert plenty of devs over to my way of thinking too.

[tddmonkey]

DI frameworks that is, not dependency injection

[ribesg]

I really just use DI because of testing, I don’t think it adds a lot of value to the actual project. But I did tests with and without and damn

[rook]

Dependency injection is just

class Thing1(val thing2: Thing2)
class Thing2()

object ObjectProvider {
  fun provideThing1(): Thing1 { return Thing1( provideThing2() ) }
  fun provideThing2(): Thing2 { return Thing2() }
}

instead of

class Thing1() {
  val thing2: Thing2

  init {
    thing2 = Thing2()
  }
}

class Thing2()

[rook]

Hard to see the value with such a contrived example, but imagine if you had to instantiate all the dependencies in a deep dependency graph. Your init block there would be massive for so many classes that depend on something in your dependency graph

[tddmonkey]

I would argue thats the smell of an overly complex object graph at that point

[tddmonkey]

We do all of our DI by hand and have yet to run up against that situation - but I worked on plenty of projects that used Spring/Guice that did have very complex object graphs.