Hacker News Reader

Hacker News

Comment by gowld | Hacker News Reader

Parent Full thread

gowld

> Dependency injection has always been such a bad name for the concept. It is just passing dependencys as arguments.

No.

Dependency Injection means using tooling to "inject" the dependency, instead of passing an explicit argument.

https://github.com/google/guice

> Think of Guice's `@Inject` as the new `new`.

Like many architecutral design patterns, toy examples don't illustrate the concept well. It's used for doing things like switching a large service-based system from using external databases and remote services for production, to in-memory everything for testing.

View on HN

Guice docs: “There are many advantages to using dependency injection, but doing so manually often leads to a large amount of boilerplate code to be written. Guice is a framework that makes it possible to write code that uses dependency injection without the hassle of writing much of that boilerplate code”

This is a common misconception. Guice’s docs delineate between dependency injection as a pattern and Guice as a framework that supports that pattern.

https://github.com/google/guice/wiki

> Like many architecutral design patterns, toy examples don't illustrate the concept well. It's used for doing things like switching a large service-based system from using external databases and remote services for production, to in-memory everything for testing.

You know, if the DB is passed as a parameter, I can do that too. Without @inject, or XML, or the god container object.

    const testdb = new InMemoryDB();
    const result = await myThing(testdb);
  expect(result.foo).toBe(42);
    expect(testdb.rows).toEqual(bar);

1. No. To quote the very same Guice documents you are pointing at: "What is dependency injection? Dependency injection is a design pattern wherein classes declare their dependencies as arguments instead of creating those dependencies directly." Literally what I said.

2. Oh boy, this is the first time I have seen Guice and it is exactly what I am talking about with languages not understanding the concept and having to be worked around with utter hacks. If you just had symbols you could bind constructors/types to and then pass those around into your implementations you could get rid of most of the common cases they mention in their docs.

Reply on news.ycombinator.com