Printf("%s %s", dependency, injection).

One of the hardest things for me to grokk in enterprise programming, was dependency injection (DI). Namely because that word already had a meaning to me, which didn’t require a lot of book readin' to understand.

In functional programming, DI means passing functions to functions.

Here’s an example function (Erlang):


add_one(N) -> N + 1.

Easy peasy; take a number, add one.

Lets inject it into a mapping function over a collection of numbers:

Eshell V12.0  (abort with ^G)

1> c(examples).

2> lists:map(examples:add_one, [0, 1, 2, 3]).
[1, 2, 3, 4]

Nice! lists:map iterates over our list and applies add_one to it.

How about Lisp?

* (DEFINE ADD-ONE (N) (+ N 1))

* (MAPCAR #'ADD-ONE '(0 1 2 3))
(1 2 3 4)

Yeah! JavaScript?

> const addOne = n => n + 1

> [0, 1, 2, 3].map(addOne)
(4) [1, 2, 3, 4]


Now all we have to do is rename map to fmap, pretend that we understand words like “monoid operation” and BAM! We’re Haskellers.

Speaking of Haskell, the nice people of the GHC were so kind as to implement this in .NET, in the form of Language-Integrated Query (LINQ):

using System.Linq;
using System.Collections.Generic;

public static int AddOne(int n) => n + 1;

new List<int>(){0, 1, 2, 3}
    .Select(AddOne); // [1, 2, 3, 4]

They called it Select as to not arouse any suspicion, hinting that this was just typed SQL, not functional programming. Sneaky sneaky.


Whenever I heard DI, this is what I thought that referred to. Turns out no.

Hold on to your hats.

public interface IGetAThing
    IThing GetThing();

public MyThingGetter : IGetAThing
    private readonly IThingFactory _factory;

    public MyThingGetter(IThingFactory factory) 
        _factory = factory;

    public IThing GetThing()
        return _factory.Get(thing.NORMAL);

public MyApi
    private readonly IGetAThing _myThingGetter;

    public MyApi(IGetAThing thing)
        _myThingGetter = thing;

    public IThing GetThing()
        return _myThingGetter.GetThing();

Sweet Alan Kay, what is this!?

Now I’ll admit to this being a bit facetious, but its only really incorrect in regards to brevity. An actual example would span this entire article.

Here’s the argument for this style of programming:

There is magic here, and it draws its power from the depth of our program:

static IHostBuilder CreateHostBuilder(string[] args) =>
                .ConfigureServices((_, services) =>
                            .AddScoped<IThingFactory, ThingFactory>()
                            .AddScoped<IGetAThing, MyThingGetter>());

(I've omitted the XML for the sake of your health)



Each invidivual component might be easy to grasp, put this comes at the cost of having to rewind the tape and insert the implementation into the slot that came before it. It’s as if you took one screen of Lisp code and shattered over several files.

Now, while you’re befriending your new best mate Go to definition (F12), there’s no one around to hold your hand once you get to testing. The plot thickens.

IMyThingGetter _myThingGetter;

public static void TearMeUp()
    _myThingGetter = new Mock<MyThingGetter>().When(MyThing.GetThing).Do((ThingType t) => { 
        t == thing.NORMAL ? new Thing() : throw new ArgumentExceptionError();

public static void Test_MyThingGetter_Should_GetAThing_When_WeWantTo()
    // ARRANGE.

    // ACT.
    var thing = _myThingGetter.GetThing(thing.NORMAL);

    // BUY MY BOOK.
    assert.Equal(thing, new Thing());


public static void WakeMeUpInside()
    _myThingGetter = null;

What does this have to do with DI?

Not much, which is my point.

Often in enterprise software, by you opting in for dependency injection of this style you seem to get the jungle attached to the Gorilla, attached to the banana you first wanted. Hence when discussing bananas, it’s not long before you’re on the subject of poison dart frogs.

There is no danger in manually constructing infrastructure by hand:

logger := log.New(log.DefaultConfig{})

dbConfig := db.NewConfig{
    Logger: logger,

db := db.New(dbConfig)

myApi := &myApi{
    Logger: logger,
    DB: db,

It’s easy to read, easy to write, easy to understand. Requires no dependencies. If you need to add anything else, it’s right here. No registration, no XML files. Just code. Your code.

If you actually need more abstract DI, interfaces are wonderful, absolutely. Passing a Reader as a dependency to a struct might have its uses, but passing it directly to your function saves you even more headaches, especially when testing.

If you’re lucky to be writing in a functional style, passing functions to other functions is even easier, and can at times offer amazing compile time safeties.

Compose functions to make smarter ones, let data be data.

Pass some values to your functions!