Hacker News Reader

Comment by garethrowlands | Hacker News Reader

The answer is that your "composition root" constructs the objects using normal code. Usually the composition root is the `main` function.

    def main:
      a = ...
      b = ...
      c = ...
      my_object = MyObject(a,b,c)
      my_object.do_something()

If you think it's ugly in `main`, then extract to another function:

    def main:
      my_object = make_my_object() # constructs my_object as above
      my_object.do_something()

I've used this pattern extensively in Kotlin and also php (ew). It works well in pretty much any language.

View on HN

If a, b and c are MyObject's "dependencies", that's dependency injection. If MyObject has no other dependencies (produces no side effects other than on a/b/c), it is fully dependency injected.

Magic, monkey-patching mess of dependency injection libraries is terrible.

Dependency injection as a concept is simple functional approach to imperative and OO programming.

> my_object = MyObject(a,b,c)

> If a, b and c are MyObject's "dependencies", that's dependency injection.

In practice, though, at least coming from a Java/.NET background, DI would be understood as using something like a decorator/annotation/some registration mechanism to let the framework handle giving you a valid instance of the class that you're after, rather than straight up using the constructor whilst filling out the parameters manually.

While your example is technically true, it wouldn't be the answer that anyone in a programming interview (at least for those languages) might expect you to provide as an example.

That said, adopting the composition root approach in a Java project (or using a god-object for all of the services) was oddly liberating and felt way more simple than mucking about with appeasing Spring's @Autowired annotation and its finnicky nature.

Like most fields of endeavour, programming has gotten infested with "smart" speak and too much terminology (let's talk the rest of Design Patterns next :D), and this same terminology changes even between different teams and not just different companies or technologies. Basically, people have a tendency to want to name pretty simple things names just so they are something special, even if they need to re-explain it every single time (there is no value in such a name, imho).

The fact that most of that terminology is misunderstood simply supports that claim above. The fact that interviews are also generally silly is besides the point too. :)

Still, none of that should be a benchmark for what something is. Dependency injection is simply about injecting a dependency instead of using it as a side-effect. You can achieve that in many ways, and the simplest is just to pass it in.

I agree with you completely! As the matter of fact, I prefer this approach. But that is dependency injection at its finest, and something that NewMountain above said is "cognitive overhead" and "indirection".

I can't speak for NewMountain but I assume he was talking about using a DI framework or container (e.g. Spring) where dependencies are defined declaratively and the framework handles the instantiation. This is what brings the indirection and the cognitive overhead.

Reply on news.ycombinator.com