DEV Community: Hugo Granja

Creating a simple dependency injection framework in Swift [Part 4]: Dynamic arguments

Hugo Granja — Wed, 06 Nov 2024 18:02:44 +0000

Introduction

Some objects need parameters only available at runtime. For example, a UserService might require a userId that's known only after a user logs in. To handle such cases we should support dynamic injection when resolving instances.

Registration

Using Swift's parameter packs, we can let our factory closures specify any arguments needed when registering services.

final class Service<T, each A> {
    let lifetime: Lifetime
    let factory: (Container, repeat each A) -> T

    init(
        _ lifetime: Lifetime,
        _ factory: @escaping (Container, repeat each A) -> T
    ) {
        self.lifetime = lifetime
        self.factory = factory
    }
}

public func register<T, each A>(
    _ type: T.Type,
    lifetime: Lifetime = .transient,
    _ factory: @escaping (Container, repeat each A) -> T
) {
    let key = String(describing: type)
    let service = Service(lifetime, factory)
    services[key] = service
}

Resolution

Upon resolution we expect to be given the same arguments that were previously specified on registration to create an instance of that type.

public func resolve<T, each A>(
    _ type: T.Type,
    arguments: repeat each A
) throws -> T {
    let key = String(describing: type)

    guard
        let service = services[key] as? Service<T, repeat each A>
    else {
        fatalError("[DI] Service for type \(type) not found!")
    }

    switch service.lifetime {
    case .transient:
        return service.factory(self, repeat each arguments)

    ...
    }
}

Usage

Assuming userId is a string, here’s how to register and resolve services:

let container = Container()

container.autoRegister(
    DatabaseService.self,
    using: DatabaseServiceImpl()
)

container.register(UserService.self) { container, userId in
    UserServiceImpl(
        databaseService: container.resolve(DatabaseService.self),
        userId: userId
    )
}

container.resolve(UserService.self, arguments: "1234")

To reduce coupling, classes requiring UserService should not directly reference the container. Instead, inject a closure to create UserService, as demonstrated below with UserJourneyFactoryImpl.

final class UserJourneyFactoryImpl: UserJourneyFactory {
    private let userServiceFactory: (String) -> UserService

    init(
        userServiceFactory: @escaping (String) -> UserService
    ) {
        self.userServiceFactory = userServiceFactoryViewFactory
    }

    func makeUserService(userId: String) -> UserService {
        return userServiceFactory(userId)
    }
}

container.register(UserJourneyFactory.self) { r in
    UserJourneyFactoryImpl(
        userServiceFactory: { userId in
            r.resolve(UserService.self, arguments: userId)
        }
    )
}

This setup allows, for example, a Coordinator to use UserJourneyFactory to create user-specific journeys in the app. Alternatively, you could inject the factory closure directly into the Coordinator.

Explore the code

Check out the full implementation of this library on BackpackDI on GitHub.

For a practical example, see MobileUseCases on GitHub.
I'd recommend looking at the entry point of the app MUCApp.swift and AppContainer.swift inside the DependencyInjection folder for a demonstration on how to centralize the configuration of the container and establish a composition root.

That’s it for this guide for now!

Let me know if you’d like to see other features or examples in the comments.

Creating a simple dependency injection framework in Swift [Part 3]: Auto-registration

Hugo Granja — Tue, 05 Nov 2024 17:12:54 +0000

Part 2

Registering services with multiple dependencies can quickly become verbose:

container.register(One.self) { _ in 
    return OneImpl()
}

container.register(Two.self) { _ in 
    return TwoImpl()
}

container.register(Three.self) { _ in 
    return ThreeImpl()
}

container.register(Example.self) { container in
    return ExampleImpl(
        first: container.resolve(One.self),
        second: container.resolve(Two.self),
        third: container.resolve(Three.self)
    )
}

Each service must be individually registered, and each dependency resolved manually. To streamline this, we can create an utility method that automatically resolves all dependencies required by an initializer. This is possible by using parameter packs, which enable handling an arbitrary number of dependencies generically.

public func autoRegister<T, each D>(
    _ type: T.Type,
    lifetime: Lifetime = .transient,
    using initializer: @escaping (repeat each D) -> T
) {
    register(type, lifetime: lifetime) { r in
        initializer(repeat r.resolve((each D).self))
    }
}

This allows us to transform our previous example into:

container.autoRegister(One.self, using: OneImpl.init)
container.autoRegister(Two.self, using: TwoImpl.init)
container.autoRegister(Three.self, using: ThreeImpl.init)
container.autoRegister(Example.self, using: Example.init)

Now, each dependency is registered concisely, without repetitive resolve calls. This method greatly reduces boilerplate and makes the code easier to read and maintain, especially as the number of dependencies grows.

In the next post, we will see how to provide arguments only available at runtime when resolving dependencies.

Part 4 - Dynamic arguments

Creating a simple dependency injection framework in Swift [Part 2]: Dependency lifetimes

Hugo Granja — Tue, 05 Nov 2024 11:23:35 +0000

Part 1

Introduction

In a dependency injection framework, lifetime management dictates how long an instance of a dependency should live after being created. Previously, we implemented transient lifetimes where each resolution creates a new instance. Here, we’ll introduce singleton and weak lifetimes.

Singleton

With a singleton lifetime a single instance is created and shared across the entire application.
Ideal for shared resources or objects with state that need to be accessible throughout the app and must maintain consistency.

Registration

We’ll start by defining an enum for lifetime cases.

public enum Lifetime {
    case transient
    case singleton
}

Since each service now has a lifetime, we encapsulate this in a service object to store both the factory and the lifetime.

final class Service<T> {
    let lifetime: Lifetime
    let factory: (Container) -> T

    init(
        _ lifetime: Lifetime,
        _ factory: @escaping (Container) -> T
    ) {
        self.lifetime = lifetime
        self.factory = factory
    }
}

To allow specifying a lifetime, we modify our register method. By default, dependencies will use the transient lifetime.

public func register<T>(
    _ type: T.Type,
    lifetime: Lifetime = .transient,
    _ factory: @escaping (Container) -> T
) {
    let key = String(describing: type)
    services[key] = Service(lifetime, factory)
}

Resolution

To support singleton instances, we add a dictionary to cache them. When resolving a singleton, we check the cache, if the instance isn’t there, we create it, store it, and return it.

public final class Container {
    private var services: [String: Any] = [:]
    private var singletonServices: [String: Any] = [:]

    ...

    public func resolve<T>(
        _ type: T.Type
    ) -> T {
        let key = String(describing: type)

        guard
            let service = services[key] as? Service<T>
        else {
            fatalError("[DI] Service for type \(type) not found!")
        }

        switch service.lifetime {
        case .transient:
            return service.factory(self)

        case .singleton:
            if let instance = singletonServices[key] {
                return instance as! T
            }
            else {
                let instance = service.factory(self)
                singletonServices[key] = instance
                return instance
            }
        }
    }
}

Weak

A weak lifetime creates a dependency only once, then holds it weakly. If no other objects retain it, it’s deallocated. This approach is useful for dependencies that should persist only if actively used.

We first add the lifetime case for weak dependencies:

public enum Lifetime {
    case transient
    case singleton
    case weak
}

To attain a weakly held value a common approach is to wrap instances in a weak container, like this:

final class WeakBox<T: AnyObject> {
    weak var value: T?

    init(value: T) {
        self.value = value
    }
}

While WeakBox allows the value to become nil when unreferenced, storing it in a dictionary retains the WeakBox itself, requiring custom clean-up like traversing the dictionary every resolution looking for nil values and removing them.
Instead, Foundation’s NSMapTable can weakly store values and it automatically clears out references when objects are no longer in use.

Note: NSMapTable doesn’t guarantee immediate deallocation, only eventual release, likely for performance reasons. If immediate cleanup is critical, consider implementing a custom dictionary that uses WeakBox with periodic clean-up of nil values.

Create an NSMapTable to weakly store dependencies:

private let weakServices: NSMapTable<NSString, AnyObject> = .strongToWeakObjects()

Update resolution to check weakServices for weakly-held instances:

public func resolve<T>(
    _ type: T.Type
) -> T {
    let key = String(describing: type)

    guard
        let service = services[key] as? Service<T>
    else {
        fatalError("[DI] Service for type \(type) not found!")
    }

    switch service.lifetime {
    case .transient:
        return service.factory(self)

    case .singleton:
        if let instance = singletonServices[key] {
            return instance as! T
        }
        else {
            let instance = service.factory(self)
            singletonServices[key] = instance
            return instance
        }

    case .weak:
        let key = NSString(string: key)

        if let instance = weakServices.object(forKey: key) {
            return instance as! T
        }
        else {
            let instance = service.factory(self) as AnyObject
            weakServices.setObject(instance, forKey: key)
            return instance as! T
        }
    }
}

Summary

This post introduced two more dependency lifetimes: singleton and weak. Future posts will cover how to create a utility method for automatically registering dependencies using their initializers as well as how to provide arguments only available at runtime when resolving dependencies.

Part 3 - Auto-register

Creating a simple dependency injection framework in Swift [Part 1]

Hugo Granja — Sat, 02 Nov 2024 11:35:19 +0000

Introduction

Dependency Injection is a fundamental pattern in software architecture that helps manage dependencies between components, leading to modular, testable, and maintainable code. In this post, we’ll explore design considerations and implement essential components.

The two main functions of a DI system are registration and resolution:

Registration defines which dependencies should be created and how they are instantiated.
Resolution retrieves instances of these registered dependencies.

Registration

To register dependencies, we could store each instance in a dictionary, using its type as the key.

public final class Container {
    private var services: [String: Any] = [:]

    func register<T>(_ type: T.Type, _ instance: T) {
        let key = String(describing: type)
        services[key] = instance
    }
}

But to conserve memory and improve startup time, we can delay instantiation until a dependency is actually needed. This is particularly beneficial for dependencies that are rarely used or expensive to initialize. Instead of directly storing instances, we store closures that build instances when called. This pattern is known as lazy instantiation.

func register<T>(_ type: T.Type, _ factory: @escaping () -> T) {
    let key = String(describing: type)
    services[key] = factory
}

Resolution

To resolve a dependency, we retrieve the registered closure from our dictionary and call it to create an instance. Since there’s no guarantee a dependency has been registered, and stored values are of type Any, we need to cast and handle errors accordingly.

We could choose to return an optional or throw an error, for demonstration purposes and since such issues are easy to identify during development, we will call fatalError if a requested dependency hasn’t been registered, this also keeps our resolution code clean and free from error-handling clutter.

public final class Container {
    private var services: [String: Any] = [:]

    public init() {}

    public func register<T>(
        _ type: T.Type,
        _ factory: @escaping () -> T
    ) {
        let key = String(describing: type)
        services[key] = factory
    }

    public func resolve<T>(
        _ type: T.Type
    ) -> T {
        let key = String(describing: type)

        guard
            let service = services[key] as? () -> T
        else {
            fatalError("Service for type \(type) not found!")
        }

        return service()
    }
}

Each time we resolve a dependency, a new instance is created. While this approach works well for many cases, it doesn’t cover all use cases. For example, singletons or shared resources might need to persist across resolutions. In future posts, we’ll discuss handling different dependency lifetimes, allowing more flexibility for shared or long-lived dependencies.

Using our DI container in an application

Now that we have our DI container set up, let’s see how we can use it in a simple application. We will create a couple of services and demonstrate how to register and resolve them using our container.

Step 1: Define some services

First, let’s define two services: DatabaseService and UserService. The DatabaseService will simulate a database connection, while the UserService will depend on DatabaseService to fetch user information.

protocol DatabaseServiceProtocol {
    func fetchUser() -> String
}

class DatabaseService: DatabaseServiceProtocol {
    func fetchUser() -> String {
        return "John Doe"
    }
}

class UserService {
    private let databaseService: DatabaseServiceProtocol

    init(databaseService: DatabaseServiceProtocol) {
        self.databaseService = databaseService
    }

    func getUser() -> String {
        return databaseService.fetchUser()
    }
}

Step 2: Register services in the DI Container

Next, we will register these services in our DI container. We will use closures to create instances of DatabaseService and UserService.

let container = Container()

container.register(DatabaseServiceProtocol.self) {
    DatabaseService()
}

container.register(UserService.self) {
    UserService(
        databaseService: container.resolve(DatabaseServiceProtocol.self)
    )
}

In the above example, you might have noticed that by capturing container in the closure for UserService we unintentionally create a retain cycle, container holds a strong reference to the closure, and the closure holds a strong reference back to container. To avoid this, we can modify the closure to accept a Container as a parameter, eliminating the strong capture.

public func register<T>(
    _ type: T.Type,
    _ factory: @escaping (Container) -> T
) {
    let key = String(describing: type)
    services[key] = factory
}

public func resolve<T>(
    _ type: T.Type
) -> T {
    let key = String(describing: type)

    guard
        let service = services[key] as? (Container) -> T
    else {
        fatalError("Service for type \(type) not found!")
    }

    return service(self)
}

With this change, our registration now looks like this:

let container = Container()

container.register(DatabaseServiceProtocol.self) { _ in
    DatabaseService()
}

container.register(UserService.self) { container in
    UserService(databaseService: container.resolve(DatabaseServiceProtocol.self))
}

We could further conform Container to a Resolver protocol and use Resolver as the argument type. This limits exposure to just the resolve method, keeping other methods hidden.

Step 3: Resolve and use the services

Now that we have registered our services, we can resolve and use them in our application.

let userService: UserService = container.resolve(UserService.self)
let user = userService.getUser()
...

Summary

This post demonstrated how to build a simple DI container in Swift, register dependencies, and resolve them in a straightforward way. In future posts, we’ll expand our DI container to support additional dependency lifetimes and more complex configurations.

Part 2 - Dependency Lifetimes