🔌 Lesson 1.2: Dependency Injection & Inversion of Control

The Tight-Coupling Problem

Consider a wholly ordinary Unity pattern. A player script wants to play a footstep sound, so it grabs the audio manager the easy way:

public class PlayerController : MonoBehaviour
{
    void Step()
    {
        // The tempting, tightly-coupled way.
        AudioManager.Instance.Play("footstep");
    }
}

It works — and it quietly creates four problems that compound as the project grows.

• Hidden dependency. Nothing in PlayerController's signature says it needs audio. You only discover it by reading every line. Its true dependencies are invisible.
• Hard-wired concrete type. It's bolted to the exact class AudioManager. Want a different implementation for mobile, or a silent one, or a fake? You can't — the type is baked in.
• Untestable. To unit-test Step() you must spin up a real AudioManager singleton and an audio system. There's no seam to insert a stand-in.
• Global mutable state. Instance is a global anyone can reach and mutate, with lifetime and initialization-order hazards that surface as null-reference bugs on scene load.

FindObjectOfType<AudioManager>() and public-field-dragged-in-the-Inspector are the same disease in different clothes: the consumer reaches out and takes a concrete dependency. The cure is to invert that.

Inversion of Control

Inversion of Control (IoC) is a simple flip in who decides. Normally a class controls its own dependencies: it constructs or looks up the concrete objects it uses. Under IoC, that control is inverted — the class stops reaching out for its dependencies and instead receives them from the outside. It says what it needs; something else decides what to give it.

Dependency Injection (DI) is the most common way to achieve IoC: dependencies are injected (passed in) rather than looked up. "Don't call us, we'll call you" — the class is handed everything it requires and is free to just use it.

Rewriting the player with injection:

public class PlayerController : MonoBehaviour
{
    private IAudioService _audio;   // depends on an abstraction

    // Something external injects the concrete service.
    public void Construct(IAudioService audio) => _audio = audio;

    void Step() => _audio.Play("footstep");
}

Now the dependency is explicit (it's in the API), abstract (an interface, not a class), and swappable (a test can pass a fake). The player no longer knows or cares which audio implementation it got. That is the whole game.

💡 IoC vs DI. IoC is the principle (control over dependencies moves outward); DI is a technique that implements it (dependencies are passed in). The Service Locator later in this lesson is also a form of IoC — a different, more compromised one.

Interfaces as Seams

The linchpin is the interface. It's the seam along which you separate what a service does from how it does it. Define the contract:

public interface IAudioService
{
    void Play(string clipId);
    void SetVolume(float volume);
}

Then supply one or more implementations behind it — the real one, plus whatever alternatives you need:

public class AudioService : IAudioService
{
    public void Play(string clipId) { /* real AudioSource work */ }
    public void SetVolume(float volume) { /* ... */ }
}

// A test double: records calls, makes no sound.
public class FakeAudioService : IAudioService
{
    public string LastClip;
    public void Play(string clipId) => LastClip = clipId;
    public void SetVolume(float volume) { }
}

Because PlayerController depends on IAudioService, you can hand it AudioService in the game and FakeAudioService in a test, and it can't tell the difference. The interface is the crack you pry the concrete type out through — the same seam idea that breaks the assembly cycles from Lesson 1.1: put the interface in Core, let both sides depend down on it.

Now visualize the payoff. Below, the same four classes are drawn two ways — tangled by direct references, then untangled through interfaces.

Three Ways to Inject

There are three places a dependency can be handed in. Each has a moment it fits.

For pure C# classes, prefer constructor injection — the object literally cannot be built in an invalid state:

public class ScoreReporter
{
    private readonly IAnalytics _analytics;
    // Can't construct a ScoreReporter without analytics — dependency is guaranteed.
    public ScoreReporter(IAnalytics analytics) => _analytics = analytics;

    public void Report(int score) => _analytics.Track("score", score);
}

A Hand-Rolled DI Container

Unity ships no DI container. To make the idea concrete — and to demystify the frameworks — let's build a minimal one. A container does two jobs: you register which implementation stands behind each interface, then you resolve an interface to get that implementation.

using System;
using System.Collections.Generic;

public class ServiceContainer
{
    // Map: interface type -> factory that produces its implementation.
    private readonly Dictionary<Type, Func<object>> _factories = new();
    private readonly Dictionary<Type, object> _singletons = new();

    // Register a single shared instance (created once, reused).
    public void RegisterSingleton<TInterface>(TInterface instance)
        => _singletons[typeof(TInterface)] = instance;

    // Register a factory: a new instance is produced on each Resolve.
    public void Register<TInterface>(Func<TInterface> factory)
        => _factories[typeof(TInterface)] = () => factory();

    // Resolve an interface to its registered implementation.
    public TInterface Resolve<TInterface>()
    {
        var type = typeof(TInterface);
        if (_singletons.TryGetValue(type, out var single))
            return (TInterface)single;
        if (_factories.TryGetValue(type, out var factory))
            return (TInterface)factory();
        throw new InvalidOperationException($"No registration for {type.Name}");
    }
}

Usage reads exactly like the frameworks: register everything once, then resolve as needed.

var container = new ServiceContainer();

// Wire concrete implementations behind their interfaces — once, up front.
container.RegisterSingleton<IAudioService>(new AudioService());
container.Register<IScoreReporter>(() =>
    new ScoreReporter(container.Resolve<IAnalytics>()));

// Later, a consumer asks for the abstraction and gets a concrete.
IAudioService audio = container.Resolve<IAudioService>();
audio.Play("footstep");

That's the whole essence of a DI container in ~30 lines: a dictionary from interface to factory, plus resolve. Production frameworks add automatic constructor injection (they inspect a type's constructor and resolve its parameters for you), lifetime scopes, and MonoBehaviour injection — but the core is this.

💡 Two lifetimes, already. Note the split above: RegisterSingleton hands back one shared instance forever; Register runs the factory every resolve for a fresh one. "Singleton vs transient" lifetime is a decision every container makes — here it's just which dictionary you used.

Service Locator vs DI

There's a close cousin worth knowing precisely because it's so tempting — and often a trap. A Service Locator is a global registry consumers pull from:

// Consumers reach into a global to FETCH dependencies.
public static class Services
{
    private static readonly ServiceContainer _c = new();
    public static void Provide<T>(T impl) => _c.RegisterSingleton(impl);
    public static T Get<T>() => _c.Resolve<T>();
}

// Somewhere deep in a class:
var audio = Services.Get<IAudioService>();   // pulled, not injected

It fixes the worst part of the singleton — at least you code against IAudioService, so implementations are swappable and fakeable. But it keeps the part DI removes: the dependency is still hidden. A class using Services.Get looks self-sufficient while secretly reaching into a global. You can't tell what it needs from its signature, and a test must populate the global locator before the class runs.

The pragmatic verdict: prefer real injection for your own gameplay code, where honest signatures pay off. A Service Locator is a reasonable pragmatic compromise for cross-cutting concerns (logging, analytics) or when retrofitting DI into a codebase that wasn't built for it — but treat it as a step down, not the goal. We'll actually use a small container-as-locator hybrid in the Module 1 mini-project (Lesson 1.5), eyes open about the trade-off.

The Composition Root

If consumers no longer create their own dependencies, someone must — in exactly one place. That place is the composition root: the single location, as close to the program's entry point as possible, where the entire object graph is assembled. It's the one spot allowed to name concrete types (it's the only box on the right of Figure 1 that touches concretes).

// The composition root — the ONE place that knows concrete types.
public class GameBootstrapper : MonoBehaviour
{
    void Awake()
    {
        var container = new ServiceContainer();

        // Register every service behind its interface.
        container.RegisterSingleton<IAudioService>(new AudioService());
        container.RegisterSingleton<ISaveService>(new FileSaveService());

        // Inject into scene objects (method injection for MonoBehaviours).
        var player = FindFirstObjectByType<PlayerController>();
        player.Construct(container.Resolve<IAudioService>());
    }
}

Everything downstream of the bootstrapper is blissfully ignorant of concrete types. Change AudioService to MobileAudioService? One line, one place. This GameBootstrapper is the seed of the Module 1 mini-project, where we grow it into a full boot sequence that initializes services asynchronously and then loads the game.

Hands-on Challenge

Summary

🚀 What's Next?

You can now structure code and wire it cleanly. Next we take control of time. In Lesson 1.3: Async & Await in Unity 6 — Awaitable, you'll move past coroutines to real async/await with Unity 6's new Awaitable type — the tool your bootstrapper will use to initialize those injected services in order before the game starts.