4 ms·

Imagine a function, that accepts another function as an argument. Badabing badaboom, the essence of dependency injection

scubbo 6y ago
Isn't that Inversion Of Control, not Dependency Injection? I've always thought of Dependency Injection as about "declaring a class in terms of its dependencies' interfaces, but allowing a framework to take responsibility for instantiating the actual dependency objects" - whereas "a function that accepts a function" is IoC (e.g. https://kentcdodds.com/blog/inversion-of-control/ https://kentcdodds.com/blog/inversion-of-control/) They're very closely related concepts - both abstractly saying "let me define unit of logic in terms of how it composes passed-in units of logic", but the distinction between "objects that need to be instantiated and injected at construction time" and "functions that are passed in at runtime" is pretty large.
- stopachka 6y ago
  I think the distinction may blurry a bit, if you consider classes as a fancy way of writing higher order functions. i.e: You can think of a class as a higher order function, that takes in a list of arguments (constructor), and returns a list of functions, that are defined within the closure of those arguments -- Hence, to me, the essence of these things are the same -- thought you are right that when people talk about dependency injection, they are also implying a specific way that these dependencies are provided (by the framework, usually magically)
  - brabel 6y ago
    > You can think of a class as a higher order function, that takes in a list of arguments (constructor), and returns a list of functions, that are defined within the closure of those arguments That's a really great definition of a class (when used as a "service" class, rather than a data class or an enum class, for example). And to me, shows that FP and OOP are really two sides of the same coin. Limit OOP to immutable data structures, and you get something extremely close to FP.
- rumanator 6y ago
  > Isn't that Inversion Of Control, not Dependency Injection? Dependency injection is one of the techniques used to implement inversion of control. > I've always thought of Dependency Injection as about "declaring a class in terms of its dependencies' interfaces, but allowing a framework to take responsibility for instantiating the actual dependency objects" - whereas "a function that accepts a function" is IoC (e.g. https://kentcdodds.com/blog/inversion-of-control/ https://kentcdodds.com/blog/inversion-of-control/) Nope, dependency injection is about passing dependencies to the objects that depends on them (i.e., inject the dependency), instead of letting the object itself instantiate them directly or actively request access to them. You may or may not depend on a framework to manage dependencies (service locator) and pass them to instances (service injector) but those are just helper components that assist with the whole dependency injection workflow. The key point is that dependencies are passed to the objects that depends on them.

scubbo 6y ago

Isn't that Inversion Of Control, not Dependency Injection? I've always thought of Dependency Injection as about "declaring a class in terms of its dependencies' interfaces, but allowing a framework to take responsibility for instantiating the actual dependency objects" - whereas "a function that accepts a function" is IoC (e.g. https://kentcdodds.com/blog/inversion-of-control/ https://kentcdodds.com/blog/inversion-of-control/) They're very closely related concepts - both abstractly saying "let me define unit of logic in terms of how it composes passed-in units of logic", but the distinction between "objects that need to be instantiated and injected at construction time" and "functions that are passed in at runtime" is pretty large.

stopachka 6y ago
I think the distinction may blurry a bit, if you consider classes as a fancy way of writing higher order functions. i.e: You can think of a class as a higher order function, that takes in a list of arguments (constructor), and returns a list of functions, that are defined within the closure of those arguments -- Hence, to me, the essence of these things are the same -- thought you are right that when people talk about dependency injection, they are also implying a specific way that these dependencies are provided (by the framework, usually magically)
- brabel 6y ago
  > You can think of a class as a higher order function, that takes in a list of arguments (constructor), and returns a list of functions, that are defined within the closure of those arguments That's a really great definition of a class (when used as a "service" class, rather than a data class or an enum class, for example). And to me, shows that FP and OOP are really two sides of the same coin. Limit OOP to immutable data structures, and you get something extremely close to FP.
rumanator 6y ago
> Isn't that Inversion Of Control, not Dependency Injection? Dependency injection is one of the techniques used to implement inversion of control. > I've always thought of Dependency Injection as about "declaring a class in terms of its dependencies' interfaces, but allowing a framework to take responsibility for instantiating the actual dependency objects" - whereas "a function that accepts a function" is IoC (e.g. https://kentcdodds.com/blog/inversion-of-control/ https://kentcdodds.com/blog/inversion-of-control/) Nope, dependency injection is about passing dependencies to the objects that depends on them (i.e., inject the dependency), instead of letting the object itself instantiate them directly or actively request access to them. You may or may not depend on a framework to manage dependencies (service locator) and pass them to instances (service injector) but those are just helper components that assist with the whole dependency injection workflow. The key point is that dependencies are passed to the objects that depends on them.