4 ms·

Dependency injection has always been such a bad name for the concept. It is just passing dependencys as arguments. Though the funniest part about it is that th

by Veserv 3y ago

Dependency injection has always been such a bad name for the concept. It is just passing dependencys as arguments. Though the funniest part about it is that the things we use every day, programming languages and build systems, still do not generally use this concept. Your imports are dependencies, you should just pass them in. Wham bam, no more environment variables, ambiguity, lookups, multiple version ambiguity, rewiring challenges, naming conflicts, etc. Well, you still need somebody to know so they can instantiate the correct dependency versions in the first place (which you could implement as a snazzy automatic dependency resolver), but all of the internal ambiguitys disappear. Replacing a library (with a drop-in compatible one) would be just instantiating a different codebase into the same symbol name which will get passed in exactly the same way as the old one.

gowld 3y ago
> 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 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.
- TreyS 3y ago
  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 https://github.com/google/guice/wiki
- Veserv 3y ago
  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.
- javcasas 3y ago
  > 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);
DonHopkins 3y ago
I prefer the term "Hollywood Principle": Don't call us, we'll call you.
ATMLOTTOBEER 3y ago
I’m just happy to see us settle on fp type ideas regardless of the name.
mcnichol 3y ago
I think this has more to do with testing, maintenance, and how it simplifies portability/flexibility. There is a point where software diving down meets the hardware coming up. When you import a library you start creating harder to separate internals and testing becomes more of a blackbox approach (I don't care what happens inside as long as my results are consistent) as opposed to unit and function. It eventually does reach a point where dependencies are harder wired but the deeper you can create this DI, the more dynamic things become (function arguments, library injection, os virtualization, even hardware at points [PCI-E, serial]). I think you are right about DI being less common but that is because it's not a natural reaction until you reach the maintenance side of software. It's much easier (and more performant) to just load it up on startup and call it directly. When you get into the way languages work you will see DI is integral to their accessibility and maintenance.

by Veserv 3y ago

gowld 3y ago

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

TreyS 3y ago
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 https://github.com/google/guice/wiki
Veserv 3y ago
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.
javcasas 3y ago
> 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);

DonHopkins 3y ago

I prefer the term "Hollywood Principle": Don't call us, we'll call you.

ATMLOTTOBEER 3y ago

I’m just happy to see us settle on fp type ideas regardless of the name.

mcnichol 3y ago

I think this has more to do with testing, maintenance, and how it simplifies portability/flexibility. There is a point where software diving down meets the hardware coming up. When you import a library you start creating harder to separate internals and testing becomes more of a blackbox approach (I don't care what happens inside as long as my results are consistent) as opposed to unit and function. It eventually does reach a point where dependencies are harder wired but the deeper you can create this DI, the more dynamic things become (function arguments, library injection, os virtualization, even hardware at points [PCI-E, serial]). I think you are right about DI being less common but that is because it's not a natural reaction until you reach the maintenance side of software. It's much easier (and more performant) to just load it up on startup and call it directly. When you get into the way languages work you will see DI is integral to their accessibility and maintenance.