Inversion of Control Containers and the Dependency Injection pattern (2004)

Though the funniest part about it is that the things we use every day, programming languages and build systems, still do not generally use this concept. Your imports are dependencies, you should just pass them in. Wham bam, no more environment variables, ambiguity, lookups, multiple version ambiguity, rewiring challenges, naming conflicts, etc.

Well, you still need somebody to know so they can instantiate the correct dependency versions in the first place (which you could implement as a snazzy automatic dependency resolver), but all of the internal ambiguitys disappear. Replacing a library (with a drop-in compatible one) would be just instantiating a different codebase into the same symbol name which will get passed in exactly the same way as the old one.

I remember when I first discovered the pattern, at a job I took 10 years after this article. The codebase seemed so clean, easy to evolve and test, even for a newbie and 'half programmer' as me - my mind was blown. I was thinking - what kind of black magic is this ?!

Say you're new to programming. What's the best place today to learn about design patterns (with python examples, since it's the most used language for beginners) in an easy and accessible way ?

This also created a bit of a spaghetti nightmare, where it was very hard to reason about which classes (services) were being used by what other services. The Inversion of Control article (later renamed/aliased Dependency Injection) was a reaction to this: it inverted the control away from the using site to the code creating the services.

(I appreciate the article does talk about Service Locator, but I think it's worthwhile having an understanding of the normalities of the time when reading it.)

I feel like there's a general feeling that:

> It is just passing dependencys as arguments.

(And: oh no, magic!)

That's often what consumers see, sure.

But it's also managed repositories of objects and factories. It's also injection logic, with scope and conditional logic. It's also runtime assembleable interception layers for objects. It's also awareness methods to observe and track your managed repositories & objects.

There's simple things we see. But zooming out from the trees I think the forest here is something more than the sun of these pieces. Programs are mostly here to juggle entities of various sorts. Mostly we programmers write code that imperatively creates & modifier objects & their references...

And Dependency Injection and Inversion of Control is having explicit tooling & stable patterns for this construction. Having actual places & tools for managing runtime objects.

I think it's so damned cool. It's so enticing to me, of being expanded beyond a programmer tool. It could & should pioneer waves of general systems research! This tech should offer external hooks beyond the app, be integrated into repls & hosting apis that let us talk to the computing objects of our world.

Invert the control! I cannot wait for us to stop doing all coding bottom up, instantiating and passing everything from the bottom.up, and starting to create some top down tools that manage the entities of the runtime!

Let's say I want to write small functions that do one thing very well:

    args = {LLM parameters, e.g., prompt}
    1. foo(args): calls the LLM API with args
    2. goo (foo(args)): uses backoff (retry) and makes sure the output is JSON
    3. hoo(goo(foo(args))): extracts and desers the JSON

    1. foo: args -> Maybe(API_res)
    2. goo: Maybe(API_res) -> Maybe(JSON)
    3. hoo: Maybe(JSON) -> Maybe(dict)

Currently args is only passed to foo. What if, depending on how things went wrong, goo needed to see args?

One approach is to make foo pass its args as well:

    foo: args -> args, output

    foo: args -> args, output
    goo: args, output -> args, output, JSON
    goo: args, output, JSON -> dict (deserialized JSON)

Honestly I think this is the most important pattern in my line of work. It has become so common for me. That when I see c# code not using it. It almost looks like another language.

Testing becomes so easy because everything is easy to mock out. Be it in a unit test using some mock framework. Or a real 'integration-test' where you write a small in memory queue mock by hand to easy your tests.

Object lifetime is easy to change and manage. Just how you register the dependency. As scoped (to http request for example) as transient (every time you ask) or singleton?

Want to do something before/after with some hook? Just Decorate the dependency and register it to the container.

Nothing feels tangled. Just inject the service. Call the method. Do the thing. No need to worry about cleanup or how to create the dependency. It's already setup.