To be fair this is using the app env for storage and is therefore a singleton acting as a global registry.
GenServers keep the callback module in the process state – and even the callback module might maintain dependencies passed at the start via the process state – which is not too different from constructor based DI in OOP.
Yes, in elixir we might not need dedicated libraries, given we have different tools for maintaining state, but the general approaches are kinda the same.
I was a fan of dependency injection containers when I was working with object-oriented web frameworks.
I was too, until I spent years of my life diligently writing unit tests, only to realize years later that those tests proved very little about the codebase.
Dependency injection is evangelized because it makes it easier to unit test with mocks.
Integration tests are vital. Unit tests are mostly useful for pure functions. Mocks lead to false confidence about the test suite.
When I came to Elixirland and learned to write mostly integration tests, I was blown away by the amount of real bugs the test suite caught.
You can do it anywhere. It’s a pretty helpful pattern for, e.g. testing API clients – use the ‘web client’ for production/staging (and maybe dev too), and a ‘test client’ for (unit) tests.
A functionally similar kind of thing is to retrieve a module name from config during compilation (by storing it in a module attribute). That’s a little less flexible than just passing a module as an argument.
