💾 Archived View for separateconcerns.com › 2022-08-15-dependency-injection.gmi captured on 2024-02-05 at 09:28:32. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
published 2022-08-15
In the list of application architecture patterns I like to use, Dependency Injection [1] comes rather high. Here is how and why I use it.
1: https://en.wikipedia.org/wiki/Dependency_injection
If you have already seen dependency injection used in practice, you may believe it requires the use of a framework such as Dagger [2]. Although I did use such frameworks - especially in Angular where it is native [3] - most of the time I use a simpler form of DI where I just pass dependencies to functions or constructors.
For instance, in Lua object-oriented code, instead of writing this:
local json = require "dkjson"
local obj_mt = {
__index = {
as_json = function(self)
return json.encode(self.data)
end
}
}
local function new_obj(data)
return setmetatable({data = data}, obj_mt)
end
local o = new_obj({foo = 5})
o:as_json()
I could write something like this:
local obj_mt = {
__index = {
as_json = function(self)
return self.json_encoder(self.data)
end
}
}
local function new_obj(data, json_encoder)
return setmetatable(
{data = data, json_encoder = json_encoder},
obj_mt
)
end
local json = require "dkjson"
local o = new_obj({foo = 5}, json.encode)
o:as_json()
Note that this follows the Dependency Inversion principle [4], which is often confused with dependency injection but not exactly the same thing. It may not be obvious in a dynamic language such as Lua but the implementation of `obj` implicitly defines the signature of the JSON encoder it expects, and you may substitute the encoder for something else.
Also, on a stylistic note, in a larger program I would probably not pass every injected dependency as a different parameter, instead I would use a single container for this.
In case you're interested, here is the same example closer to how I'd write it in practice in Teal [5]:
local type JsonAble = {string: any}
local type JsonEncoder = function(JsonAble): string
local record ObjDeps
json_encoder: JsonEncoder
end
local record Obj
data: JsonAble
as_json: function(Obj): string
_deps: ObjDeps
end
local obj_mt = {
__index = {
as_json = function(self: Obj): string
return self._deps.json_encoder(self.data)
end
}
}
local function new_obj(data: JsonAble, deps: ObjDeps): Obj
return setmetatable({data = data, _deps = deps}, obj_mt)
end
local json = require "dkjson"
local o = new_obj(
{foo = 5},
{json_encoder = json.encode as JsonEncoder}
)
o:as_json()
Now let us see a few use cases for this.
3: https://angular.io/guide/dependency-injection
4: https://en.wikipedia.org/wiki/Dependency_inversion_principle
5: https://github.com/teal-language/tl
Probably the most well-known use case for DI is simplifying testing of code that does I/O, for instance code that makes network requests or interacts with a database. It makes it easy to replace the problematic part with a mock. You can mock just what you need or the entire dependency, for instance you can replace Redis with fakeredis [6].
6: https://luarocks.org/modules/catwell/fakeredis
This is a less well-known but very good use-case, especially in Lua. Let us consider my JSON example above. Users of this code may want to use dkjson [7], but maybe they want to use a faster, pure C module, or maybe they are running in OpenResty and have cjson [8] available. With dependency injection, it's easy to just use it.
7: https://luarocks.org/modules/dhkolf/dkjson
8: https://openresty.org/en/lua-cjson-library.html
This is in fact the use case that prompted me to write this blog post. I was writing some algorithmic code in Teal for which I had a reference in Python, and I wanted to apply the dual-implementation comparison technique I like [9]. However, this was AI code that had random parts.
What I did was that I refactored the code in both languages so that all sources of randomness were injected, and then I injected deterministic pseudo-random values instead, which meant I could now compare the state of both implementations at all times and easily debug things such as numerical problems.
9: https://blog.separateconcerns.com/2013-06-20-three-years-proprietary-projects.html#seed
DI is a great tool, but it tends to make code a bit more complicated, so for instance I do not use it to inject pure functions or libraries from the same codebase.
If you have used Angular with Storybook [10], you may know what abuse of DI looks like. It can be super verbose because sometimes you need to inject a lot of things you do not really care about for it to work.
A way to work around that if you still want to use DI may be to have sensible defaults for some injected objects. That way you can still override them if needed, but you can still have simple sample code.