43 ms·

I'm very curious to hear from someone who likes DI in a non-OOP language - why? What techniques do you use to make the level of indirection feel like a help, r

I'm very curious to hear from someone who likes DI in a non-OOP language - why? What techniques do you use to make the level of indirection feel like a help, rather than a hindrance, in your codebase? Reading this article reminded me that DI has a lot of advocates, but I've never heard a compelling reason to use it in most codebases.

starbugs 3y ago
* Keeping a function easy to understand without having to think about the rest of the codebase * Minimizing non-local state * Keeping things testable * Keeping code reusable without having to find and copy a lot of other code from a codebase/refactor completely Note: I am not talking about DI frameworks here, because I don't like them.
BlackFly 3y ago
How else are you going to manage dependent options of an algorithm but to inject the dependency inside of its configuration? Say in rust, you have some struct backing a trait. But your implementation of the trait can also have a variety of options which are parameterized by some other trait. You end up with a generic struct: that is all dependency injection is. Every generic struct in rust is an example of dependency injection. Instead, dependency injection frameworks help people instantiate large dependency graphs with some lifecycle management. Those I am a bit of the take it or leave it opinion.
- starbugs 3y ago
  In an OOP codebase, what I usually find is an if or switch with some enum which then calls something along the lines of SomeManager.shared.whatever(). Sorry for being cynical. I can't help it.
  - BlackFly 3y ago
    You see that in OOP codebases where the authors don't know any compositional patterns. Then the only way to thread logic together is statically, so singletons and the enums like you mention.
    - starbugs 3y ago
      Those that don’t know these patterns are way less of a problem than those who know them, know that it would be better to use them, but reject to do so. Because they are effectively lazy and don’t care about other people that have to work with their code in the future. Unfortunately, there are many of those. What I often find is that management in organizations rewards these people because they get quick results. The cost to the customer and the team is well hidden until it’s too late.
- gemstones 3y ago
  I guess I don't typically think of things like Go's context when considering DI, but it serves conceptually the same purpose. My beef is more with the DI frameworks, I suppose.
  - BlackFly 3y ago
    I honestly think that DI frameworks don't add a lot of value (for me, when I work alone). You annotate some magic on a class or you call that constructor in your composition root. The explicit thing is nicer from my perspective, but most people don't know how to make it modular very well so the DI frameworks pop up to save people the trouble of learning. I prefer DI framework code to singleton spaghetti though, so...
likeclockwork 3y ago
Have a look at Integrant from Clojure: https://github.com/weavejester/integrant https://github.com/weavejester/integrant
ickyforce 3y ago
> I'm very curious to hear from someone who likes DI in a non-OOP language - why? The alternative to DI is keeping dependencies in a global state (global variables, singletons, whatever) and that is a maintainability nightmare for any codebase above a certain size. I don't think that it matters if the language is OOP or not, the issue is the same.
- dial9-1 3y ago
  modules just do it better
gitgud 3y ago
Dependency Injection allows for more incremental development in my experience. As each new class is simply added to a constructor somewhere and the system takes care of constructing things. Regardless of what the article says, mocking in tests is easier. As you’re only depending on injected classes, you just mock a class and inject it in a test. Like any architectural decision “it depends”. But I think it scales well, enforces modularity, automates construction logic (which can be huge) and is quite nice to work with generally.
lmm 3y ago
> I'm very curious to hear from someone who likes DI in a non-OOP language - why? The same reason as in OO languages. Clean separation of startup and runtime. Testability. Ability to avoid duplication and make changes in one place. > What techniques do you use to make the level of indirection feel like a help, rather than a hindrance, in your codebase? Separation of concerns/responsibilities always involves indirection. Using something like a free monad would be more indirection. I can't really give any useful advice beyond "factor your app well" and "split concerns/responsibilities at points that make sense"
randomdata 3y ago
I'm more curious to hear from Typescript developers who stand by using the global scope for dependency injection. I see that pattern a lot in Typescript code. I suspect it is because Typescript doesn't properly support prototype function assignment, which makes scoped injection painfully ugly.

starbugs 3y ago

* Keeping a function easy to understand without having to think about the rest of the codebase * Minimizing non-local state * Keeping things testable * Keeping code reusable without having to find and copy a lot of other code from a codebase/refactor completely Note: I am not talking about DI frameworks here, because I don't like them.

BlackFly 3y ago

How else are you going to manage dependent options of an algorithm but to inject the dependency inside of its configuration? Say in rust, you have some struct backing a trait. But your implementation of the trait can also have a variety of options which are parameterized by some other trait. You end up with a generic struct: that is all dependency injection is. Every generic struct in rust is an example of dependency injection. Instead, dependency injection frameworks help people instantiate large dependency graphs with some lifecycle management. Those I am a bit of the take it or leave it opinion.

starbugs 3y ago
In an OOP codebase, what I usually find is an if or switch with some enum which then calls something along the lines of SomeManager.shared.whatever(). Sorry for being cynical. I can't help it.
- BlackFly 3y ago
  You see that in OOP codebases where the authors don't know any compositional patterns. Then the only way to thread logic together is statically, so singletons and the enums like you mention.
  - starbugs 3y ago
    Those that don’t know these patterns are way less of a problem than those who know them, know that it would be better to use them, but reject to do so. Because they are effectively lazy and don’t care about other people that have to work with their code in the future. Unfortunately, there are many of those. What I often find is that management in organizations rewards these people because they get quick results. The cost to the customer and the team is well hidden until it’s too late.
gemstones 3y ago
I guess I don't typically think of things like Go's context when considering DI, but it serves conceptually the same purpose. My beef is more with the DI frameworks, I suppose.
- BlackFly 3y ago
  I honestly think that DI frameworks don't add a lot of value (for me, when I work alone). You annotate some magic on a class or you call that constructor in your composition root. The explicit thing is nicer from my perspective, but most people don't know how to make it modular very well so the DI frameworks pop up to save people the trouble of learning. I prefer DI framework code to singleton spaghetti though, so...

likeclockwork 3y ago

Have a look at Integrant from Clojure: https://github.com/weavejester/integrant https://github.com/weavejester/integrant

ickyforce 3y ago

> I'm very curious to hear from someone who likes DI in a non-OOP language - why? The alternative to DI is keeping dependencies in a global state (global variables, singletons, whatever) and that is a maintainability nightmare for any codebase above a certain size. I don't think that it matters if the language is OOP or not, the issue is the same.

dial9-1 3y ago
modules just do it better

gitgud 3y ago

Dependency Injection allows for more incremental development in my experience. As each new class is simply added to a constructor somewhere and the system takes care of constructing things. Regardless of what the article says, mocking in tests is easier. As you’re only depending on injected classes, you just mock a class and inject it in a test. Like any architectural decision “it depends”. But I think it scales well, enforces modularity, automates construction logic (which can be huge) and is quite nice to work with generally.

lmm 3y ago

> I'm very curious to hear from someone who likes DI in a non-OOP language - why? The same reason as in OO languages. Clean separation of startup and runtime. Testability. Ability to avoid duplication and make changes in one place. > What techniques do you use to make the level of indirection feel like a help, rather than a hindrance, in your codebase? Separation of concerns/responsibilities always involves indirection. Using something like a free monad would be more indirection. I can't really give any useful advice beyond "factor your app well" and "split concerns/responsibilities at points that make sense"

randomdata 3y ago

I'm more curious to hear from Typescript developers who stand by using the global scope for dependency injection. I see that pattern a lot in Typescript code. I suspect it is because Typescript doesn't properly support prototype function assignment, which makes scoped injection painfully ugly.