Swifty Protocol-Oriented Dependency Injection

The key to dependency injection is protocols – from there sprouts many variations, flavours, and techniques. Although this is yet another dependency injection™ blog post, I would like to share a pure Swift, battle-tested DI implementation with no outside dependencies or magic. It combines protocol extension and type erasure to give you a solid, flexible dependency injection that works great with unit test and even frameworks.

UPDATE: Created a more modern, property wrapper version here.

The Dependency Container

The first thing we must do is come up with a container that will house all our dependencies. This will be referenced later from consumers to grab dependencies they want.

protocol Dependency {
    func resolveService() -> HTTPServiceType
    
    func resolveWorker() -> AuthenticationWorkerType
    func resolveService() -> AuthenticationService
    
    func resolveWorker() -> UsersWorkerType
    func resolveStore() -> UsersStore
    func resolveCache() -> UsersStore
}

Now that we got the blueprint to our container and its dependency protocols, let’s implement the concrete dependency instances:

class CoreDependency: Dependency {
    
    func resolveService() -> HTTPServiceType {
        return HTTPService()
    }
    
    func resolveWorker() -> AuthenticationWorkerType {
        return AuthenticationWorker(
            service: resolveService()
        )
    }
    
    func resolveService() -> AuthenticationService {
        return AuthenticationNetworkService(
            httpService: resolveService()
        )
    }
    
    func resolveWorker() -> UsersWorkerType {
        return UsersWorker(
            store: resolveStore(),
            cacheStore: resolveCache()
        )
    }
    
    func resolveStore() -> UsersStore {
        return UsersNetworkStore(
            httpService: resolveService()
        )
    }
    
    func resolveCache() -> UsersStore {
        return UsersCoreDataStore() //..or use UsersRealmStore
    }
}

This is where the main meat of the dependency injection occurs. The dependency objects implement the protocols so the concrete types are hidden from the caller. This way, the dependency types can be swapped out underneath without affecting the rest of the application.

Also notice that some dependencies reference other dependencies within the container. The implications of this is powerful because you are building a dependency graph and any part of it can be changed which will cascade.

The Dependencies

There are no singleton dependencies in our container because we always want to deal with immutable objects, otherwise state management will bite you later. Instead, its a factory serving fresh instances. The dependencies are structs that implement the protocols.

Here’s an example of some of the dependencies:

protocol HTTPServiceType {...}

struct HTTPService: HTTPServiceType {
    ...
}

///

protocol AuthenticationService {...}

struct AuthenticationNetworkService: AuthenticationService {
    private let httpService: HTTPServiceType
    
    init(httpService: HTTPServiceType) {
        self.httpService = httpService
    }
}

///

protocol AuthenticationWorkerType {...}

struct AuthenticationWorker: AuthenticationWorkerType {
    private let service: AuthenticationService
    
    init(service: AuthenticationService) {
        self.service = service
    }
}

We’re using classic constructor injection to feed the dependencies in.

The HTTPService dependency handles the raw network requests/responses and where you would import Alamofire for example. Never leak your 3rd-party dependencies to the rest of the app! Instead, encapsulate it under one of your custom dependencies. That’s what HTTPService will do for Alamofire.

Now based on our dependency container, HTTPService gets injected into AuthenticationNetworkService so it can make the REST API endpoint calls. It doesn’t know that it’s using Alamofire underneath and can be completely swapped out for another network library or URLSession.

From here, AuthenticationNetworkService gets injected into AuthenticationWorker that gets referenced by the rest of the app. This way, the REST API server or endpoints can be completely swapped out and your app wouldn’t have to know. It would still call the AuthenticationWorker API’s.

The Injection

It’s now time to start using our dependency container. We will use a protocol extension to pass in the dependency container so the caller can start resolving the dependency types it wants.

We need a singleton to hold a reference to the dependency container. So although we couldn’t get away from singletons altogether, the dependency container is a factory and still serving immutable instances.

/// The singleton dependency container reference
/// which can be reassigned to another container
struct DependencyInjector {
    static var dependencies: Dependency = CoreDependency()
    private init() { }
}

/// Attach to any type for exposing the dependency container
protocol HasDependencies {
    var dependencies: Dependency { get }
}

extension HasDependencies {
    
    /// Container for dependency instance factories
    var dependencies: Dependency {
        return DependencyInjector.dependencies
    }
}

The DependencyInjector should be configured early on in the app lifecycle. That way, your frameworks can have its own dependency container, such as CoreDependency, and consumers can override any of the dependencies it desires. This works great for consumers who want to use a different UserDefaults app group or Keychain access group.

We do this in the willFinishLaunchingWithOptions:

extension UIApplicationDelegate {
    
    func configure(dependency: Dependency) {
        DependencyInjector.dependencies = dependency
    }
}

///

class AppDependency: CoreDependency {
    
    override func resolveCache() -> UsersStore {
        return UsersRealmStore()
    }
}

///

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication, willFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool {
        configure(dependency: AppDependency())
        return true
    }
}

Finally, the protocol extension for HasDependencies is used to provide the dependency container to whoever wants it:

class ViewController: UIViewController, HasDependencies {

    private lazy var authenticationWorker: AuthenticationWorkerType = dependencies.resolveWorker()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        authenticationWorker.login(with: "whatever") {
            //completed
        }
    }
}

The Unit Test

Not only does this dependency injection work great for frameworks, but of course works great for unit tests. It can be configured on a global and scoped level too!

For the global level of your unit tests, you can create a TestDependency that subclasses CoreDependency:

class TestDependency: CoreDependency {
    
    // Override with mocks, spy, or whatever
    
    override func resolveService() -> AuthenticationService {
        return AuthenticationTestService()
    }
}

struct AuthenticationTestService: AuthenticationService {
    var isAuthorized: Bool {
        return true
    }
    
    func signup(with request: Any, completion: @escaping () -> Void) {
        print("AuthenticationTestService.signup")
    }
    
    func login(with request: Any, completion: @escaping () -> Void) {
        print("AuthenticationTestService.login")
    }
    
    func logout() {
        
    }
}

You set this in your setUp() function of your test case:

class MyCore_Tests: XCTestCase, HasDependencies {
    
    override func setUp() {
        super.setUp()
        
        // Use test dependency or even a scoped one to the test!
        DependencyInjector.dependencies = TestDependency()
    }
}

What’s even more powerful is you can create a scoped dependency container for a specific test case, see ScopedDependency:

class MyCore_Tests: XCTestCase, HasDependencies {
    
    private lazy var authenticationWorker: AuthenticationWorkerType = dependencies.resolveWorker()
    private lazy var usersWorker: UsersWorkerType = dependencies.resolveWorker()
    
    override func setUp() {
        super.setUp()
        
        // Use test dependency or even a scoped one to the test!
        DependencyInjector.dependencies = ScopedDependency()
    }
    
    override func tearDown() {
        super.tearDown()
        
        // Set dependencies back to what it was
        DependencyInjector.dependencies = TestDependency()
    }
    
    private class ScopedDependency: TestDependency {
        
        override func resolveService() -> HTTPServiceType {
            return MockHTTPService()
        }
    }
    
    private struct MockHTTPService: HTTPServiceType {
        
        public func post(url: String, parameters: [String: Any], headers: [String: String]?, completion: @escaping () -> Void) {
            //Blah, blah
            print("MockHTTPService.post")
        }
        
        public func get(url: String, parameters: [String: Any], headers: [String: String]?, completion: @escaping () -> Void) {
            //Blah, blah
            print("MockHTTPService.get")
        }
    }
}

extension MyCore_Tests {
    
    func testAuthenticationExample() {
        authenticationWorker.signup(with: "whatever") {
            XCTAssertTrue(true)
        }
    }
    
    func testUserExample() {
        usersWorker.fetchCurrent {
            XCTAssertTrue(true)
        }
    }
    
}

Conclusion

The combination of a dependency container, a protocol extension to expose it, and immutable dependencies give you a pure Swift DI that works well with frameworks and unit tests. See this working example to try it out.

HAPPY CODING!!

More Reading

• Dependency injection using factories in Swift
• A Swift-y Approach to Dependency Injection
• Using protocol compositon for dependency injection