Compile-Time DI vs. Run-Time DI
dimes.github.io
dimes.github.io
I'm not trying to rain on the author's parade. I genuinely don't understand the benefit—especially in relation to the complexity of adding an extra dependency and layer to my application.
I’ve found that the advantages for DI frameworks (besides encouraging more unit tests and enabling them) to be more valuable for bigger and messier projects.
Conversely, a declarative, step-wise func main, with components manually constructed and passed to each other as dependencies where necessary, is sometimes tedious, but never confusing, and always refreshingly easy to maintain, no matter how much time you've spent with the project.
var database = new DatabaseFacade(config.get("db.host"), config.get("db.port", Integer::parseInt));
var users = new UserRepository(database);
var catalogue = new ProductRepository(database);
var cart = new ShoppingCartController(users, catalogue);
The primary application I work on has hundreds of classes that get dependencies injected through DI. Many can be and are singletons, but many - including some very commonly used ones - cannot.
If I manually wired dependencies it would add thousands of lines of code, and there are some where if I changed the constructor parameters I would have to modify 1000+ call sites.
And this isn't even a particularly massive or complex application.
Remember that this setup code is just code, so if you find that adding a constructor parameter means modifying a thousand call sites, you should probably refactor it a bit first, so that it doesn't.
That being said, this approach to DI does take some tedious manual work to maintain. But by paying that cost, you get to take a magical DI framework out of the picture entirely.
https://blog.ploeh.dk/2014/06/10/pure-di/
https://stackoverflow.com/questions/6277771/what-is-a-compos...
var db IDatabase
{
if dev_mode
db = new InMemDatabase()
else
db = new PostgresDatabase(dsn)
}
var users = new UsersRepository(db)
var catalogue = new ProductRepository(db)
// ...
var cart = new ShoppingCartController(users, catalogue, logger, metrics, ...)On the other hand, I've also found myself avoiding writing code which requires deep mocks like that in order to test. Functional core, imperative shell helps with that.
I can understand some hesitation about using a dependency injection framework. Some of them can be very hard to reason about (especially the run time frameworks). However, they don't have to be that hard to reason about. My personal favorite is a compile time dependency injection framework for scala called Macwire[1]. In scala, you might do manual dependency injection like this:
val instantiated = new Class(dependency1, dependency2)
val instantiated = wire[Class]
What! This is essential knowledge. Without it, how can you possibly build a coherent mental model of a program?! I’ve never heard this justification before, it’s bonkers.
EDIT - You have a tree of dependencies. This is something you care about. In order to create that tree in code, you have to convert it to a linear series of statements. This conversion is something you don't really care about as long as you end up with the tree you want. Dependency injection frameworks should make it so you can declaratively specify that tree without having to worry about how it is actually constructed.
The point being made is that just writing the construction statements in the main method is exactly "declaratively specify[ing] that tree", and that "having to worry about how it is actually constructed" is incredibly valuable knowledge to maintainers, because it allows them to see explicitly how components are constructed, and how they interact with each other. It's not something you want to hide with a framework, it's something you want to lift up, front-and-center, so everyone can see it.
Isn't it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc?
The decision to use XML was actually quite reasonable for many developers given the constraints at the time. Thankfully Java has mostly seen the light these days, adding generics, first-class functions, and good-enough multiple inheritance (though it still has very restricted and cumbersome metaprogramming - classes are not first-class, and the lack of HKT makes it very difficult to work with functions generically since you can't abstract over arity), and people are gradually realizing that this different environment warrants different choices. (Companies still have terrible policies about code versus "config" though).
$ ./my-server -reporting=email
vs
setting com.mycompany.package.subpackage.di.providers.abstract.ReportingProvider to com.mycompany.package.subpackage.di.providers.impl.EmailReportingProviderImpl.
The whole DI is a wrong concept. Dependencies should be instantiated at top level (main function) and explicitly passed down the call graph as interface instances.
DI breaks the call graph with (configurable) side effects. If you pass down dependencies explicitly you don't even need mocking frameworks for testing.
Passing dependencies also qualifies as DI and is for the benefit of the developer. Maybe you are only talking about DI frameworks or containers in which case I share some skepticism but in general the concept of DI is pretty sound.
well, then how do you do it ? what do you do if your client / boss tells you "I want to configure the plug-ins & classes availables in the software through some file editing without having to recompile anything" and your codebase is in C++ / Java / Go / D / Rust ...
You compile all the (tested) combinations as static executables and shove them all into the release package.
But you might also encounter DI config files for specific environments, like development where you inject MockMailer, TrivialLogger and InMemoryDatabase instead of RealLifeMailer, CloudLogger and ActualDatabase.
Catching things early and often. Tooling that shifts things further left in the pipeline is my go-to default.
(This is not a criticism of Rust. It is not a criticism of a work to place it correctly in its historical context. Very few things consist entirely of novel ideas, and very few of those are any good, if any.)