Extenject Documentation

Dependency Injection is a design pattern used to achieve loose coupling between classes. Instead of a class creating its own dependencies (which leads to tight coupling), dependencies are "injected" into the class, typically via its constructor.

The Problem: Tight Coupling

When a class instantiates its own dependencies, it becomes hard to change implementations without modifying the class itself:

public class Foo
{
    ISomeService _service;

    public Foo()
    {
        _service = new SomeService(); // Tight coupling to concrete SomeService
    }
}

The Solution: Dependency Injection

By passing the dependency through the constructor, the class only cares about the interface, not the concrete implementation:

public class Foo
{
    ISomeService _service;

    public Foo(ISomeService service)
    {
        _service = service;
    }
}

The Composition Root

To avoid passing dependencies manually through every layer of your application (the "prop drilling" problem), DI frameworks like Extenject automate the process. The responsibility of deciding which concrete implementations to use is moved to a single location called the Composition Root. Extenject automates the creation and wiring of this object graph.

Extenject allows you to control the disposal order of classes implementing IDisposable via execution order settings. However, Unity does not guarantee a deterministic destruction order for GameObjects or scenes during application quit.

Ensuring predictable destruction for GameObjects

To ensure IDisposable bindings are destroyed before scene GameObjects, place your objects as children of the SceneContext. You can enable the Parent New Objects Under Scene Context setting on the SceneContext component to automatically parent all dynamically instantiated objects under the context.

Ensuring deterministic scene destruction on quit

By default, Unity's destruction order for scenes and DontDestroyOnLoad objects (including ProjectContext) is non-deterministic. To force a sensible order, set the Zenject setting Ensure Deterministic Destruction Order On Application Quit to true.

When enabled, scenes are destroyed in the reverse order they were loaded, followed by the destruction of DontDestroyOnLoad objects.

Warning: This setting is disabled by default because it can cause crashes on Android.

An Abstract Factory is used when you want a factory to return an interface rather than a concrete class. This allows you to swap implementations at runtime or during installation without changing the consumer code.

To implement this:

1. Define an interface (e.g., IPathFindingStrategy).
2. Create a factory class inheriting from PlaceholderFactory<IInterface>.
3. In your installer, use Container.BindFactory<IInterface, YourFactory>().To<ConcreteImplementation>().

Example

public interface IPathFindingStrategy { /* ... */ }
public class AStarPathFindingStrategy : IPathFindingStrategy { /* ... */ }

public class PathFindingStrategyFactory : PlaceholderFactory<IPathFindingStrategy> { }

// In the Installer
public override void InstallBindings()
{
    if (UseAStar)
    {
        Container.BindFactory<IPathFindingStrategy, PathFindingStrategyFactory>().To<AStarPathFindingStrategy>();
    }
    else
    {
        Container.BindFactory<IPathFindingStrategy, PathFindingStrategyFactory>().To<RandomPathFindingStrategy>();
    }
}

To avoid coupling subscribers to concrete signal types, you can use Abstract Signals. Instead of subscribing to a specific struct like SignalLevelCompleted, you can have multiple signal structs implement a common interface (e.g., ISignalGameSaver) and subscribe to that interface instead.

Key API differences:

• Declaration: Use Container.DeclareSignalWithInterfaces<T>() instead of DeclareSignal<T>(). This registers both the concrete type and its implemented interfaces.
• Firing: Use signalBus.AbstractFire<T>() instead of signalBus.Fire<T>(). AbstractFire will fire the signal via its interfaces. If the signal was not declared with interfaces using DeclareSignalWithInterfaces, it will throw an exception.

This allows a system (like a SoundSystem) to react to any signal that implements a specific interface (like ISignalSoundPlayer) without needing to know the specific event that triggered it.

// 1. Define interfaces for capabilities
public interface ISignalGameSaver {}
public interface ISignalSoundPlayer { int SoundId { get; }
}

// 2. Implement interfaces in concrete signal structs
public struct SignalCheckpointReached : ISignalGameSaver, ISignalSoundPlayer
{
    public int SoundId => 2;
}

// 3. In your Installer, declare with interfaces
Container.DeclareSignalWithInterfaces<SignalCheckpointReached>();

// 4. In your System, subscribe to the interface
public class SaveGameSystem
{
    public SaveGameSystem(SignalBus signalBus)
    {
        signalBus.Subscribe<ISignalGameSaver>(x => SaveGame());
    }
    void SaveGame() { /* ... */ }
}

// 5. Fire using AbstractFire
public class Example
{
    SignalBus signalBus;
    public void CheckpointReached() => signalBus.AbstractFire<SignalCheckpointReached>();
}