4 ms·

But can’t you do your DI by hand? The frameworks can really become absurd in their complexity for a lot of tasks (I’m sure they make sense in many situations).

by jjice 1y ago

But can’t you do your DI by hand? The frameworks can really become absurd in their complexity for a lot of tasks (I’m sure they make sense in many situations). DI is a concept that can be orchestrated with normal code at the top of the execution just fine, eliminating a lot of cruft. To be fair, the numbers you h the row out sound like a framework becomes valuable, but most places I’ve seen DI frameworks, they could be replaced with manual DI and it would be much simpler.

danpalmer 1y ago
When you say "do your DI by hand", do you mean wiring up each case, or do you mean writing a DI system that treats the cases generically? The former is what I'm suggesting becomes untenable at some point. The latter is just writing your own DI framework for, which I think would be fine. DI frameworks are complicated, but they're a constant level of complicated, they don't get more complicated as the codebase grows. Not using a DI framework is simple at the beginning, but it grows, possibly exponentially, and at some point crosses the line of constant complexity from a DI framework. Finding where those lines intersect is just good engineering. Ignoring the fact that they do intersect is not.
- tcfhgj 1y ago
  > Not using a DI framework is simple at the beginning, but it grows, possibly exponentially, and at some point crosses the line of constant complexity from a DI framework. How so?
  - danpalmer 1y ago
    Look at my example numbers, and think through how you would write the setup process for that piece of software. You'd need a ton of conditionals checking all sorts of different things, woven throughout the codebase, in many different classes, etc. With a DI framework of some kind, those conditionals would likely not exist, instead you'd be able to specify all the options, and the DI framework takes over stitching them together and finding the dependencies between them.

by jjice 1y ago

danpalmer 1y ago

When you say "do your DI by hand", do you mean wiring up each case, or do you mean writing a DI system that treats the cases generically? The former is what I'm suggesting becomes untenable at some point. The latter is just writing your own DI framework for, which I think would be fine. DI frameworks are complicated, but they're a constant level of complicated, they don't get more complicated as the codebase grows. Not using a DI framework is simple at the beginning, but it grows, possibly exponentially, and at some point crosses the line of constant complexity from a DI framework. Finding where those lines intersect is just good engineering. Ignoring the fact that they do intersect is not.

tcfhgj 1y ago
> Not using a DI framework is simple at the beginning, but it grows, possibly exponentially, and at some point crosses the line of constant complexity from a DI framework. How so?
- danpalmer 1y ago
  Look at my example numbers, and think through how you would write the setup process for that piece of software. You'd need a ton of conditionals checking all sorts of different things, woven throughout the codebase, in many different classes, etc. With a DI framework of some kind, those conditionals would likely not exist, instead you'd be able to specify all the options, and the DI framework takes over stitching them together and finding the dependencies between them.