什么是控制反转（Inversion of Control）？
控制反转就是把传统的控制逻辑委托给另一个类或框架来处理，客户方只需实现具体的任务而不需要关心控制逻辑。
举个例子，比如存在客户方和服务方两个类，客户方需要调用服务方的函数来执行某个逻辑。在传统的编程方式中，客户方根据自己的需求直接去调用服务方的函数从而达到目的。而控制反转，则是把控制逻辑交给服务方，服务方提供了一个控制流的框架，具体的内容需要由客户方来填充，也就是说对流程的控制反转了，现在是服务方调用客户方。据说好莱坞有句名言 Don't call us, we'll call you，差不多就是这个意思。以上的服务方也可以是库代码或者框架。
在 iOS 开发中，有一个非常常见的控制反转的实现，可能很多人都没有意识到这个就是控制反转，那就是 completionHandler，或者说 callback。
API.request(completion: { data in
handleData(data)
})
在这个例子中，业务方只需要关系拿到数据以后干什么，而不关心 completion 的调用时机，把 completion 的调用委托给了网络库，这就是控制反转。
控制反转可以让主要任务和控制逻辑分离，可以提升代码的模块性和扩展性，让代码松耦合，并可以让写测试代码变得简单。
常见的控制反转的实现有：
- 服务定 位 器（Service Locator）
- 依赖注入
- 上下文查找（Contextualized lookup）
- 模板方法（Template method）
- 策略模式（Strategy design pattern）
本文仅讨论依赖注入这种实现，暂不讨论其他的实现。
什么是依赖注入？
依赖注入是控制反转的一种具体实现。它在类的外部创建这个类的依赖对象，然后通过某个方式把这个依赖对象提供给类。通过依赖注入，把依赖对象的创建和绑定都移动到了类的外部。
先看下面的例子：
class Car {
var tyres: [Tyre]
init() {
let tyre1 = Tyre()
let tyre2 = Tyre()
let tyre3 = Tyre()
let tyre4 = Tyre()
tyres = [tyre1, tyre2, tyre3, tyre4]
}
}
这个例子中构建了一个汽车对象，汽车对象的构建需要拼装 4 个轮胎。这个代码的缺点显而易见，就是轮胎的创建逻辑和汽车本身耦合了。当我们想换成另一种轮胎时，或者 Tyre 类调整了实现在构造时添加了一个参数，都必须改动 Car 类中的代码。
用依赖注入的方式，把依赖对象的创建和绑定挪到类外部，就能解决这类问题。
class Car {
var tyres: [Tyre]
init(types: [Tyre]) {
self.types = types
}
}
再举个例子，App 开发中常见的网络请求 -> 数据处理 -> 数据渲染流程，传统方式开发如下：
// DataViewModel.swift
func loadData() {
API.requestData(id: 2222, completion: { data in
self.handleData(data)
})
}
这样的代码是无法测试的，因为 ViewModel 和具体的网络请求实现耦合了。为了让 loadData 这个方法可以被测试，应该抽象一个网络请求的接口，然后从外部注入这个接口的实现。如下代码：
protocol Networking {
func requestData(id: Int, completion: (Data) -> Void)
}
让 DataViewModel 拥有一个需要注入的属性对象：
class DataViewModel {
let networking: Networking
init(networking: Networking) {
self.networking = networking
}
}
loadData 方法修改如下：
func loadData(completion: (() -> Void)?) {
networking.requestData(id: 2222, completion: { data in
self.handleData(data)
})
}
这样把具体的网络请求实现转移到外部注入，在测试的时候就可以简单的实现一个模拟的网络请求，这样就可以写出测试代码：
func testLoadData() {
let networking = MockNetworking()
let viewModel = DataViewModel(networking: networking)
let expectation = XCTestExpectation()
viewModel.loadData {
expectation.fulfill()
}
wait(for: [expectation], timeout: .infinity)
XCTAssertTrue(viewModel.data.xxxx)
}
依赖注入最大的优点就是实现了类之间的解耦。什么叫解耦，解耦就是两个类之间虽然存在一些依赖关系，但是当其中任何一个类的实现发生改变时，另一个类的实现完全不受影响，解耦本身是通过抽象接口来实现的，因此依赖注入也需要抽象接口，并且依赖注入将依赖的创建转移到了客户类的外部，把依赖的创建逻辑也和客户类本身解耦。这样无论是替换依赖对象的实现类，还是替换依赖对象类实现中的某个部分，客户方类都不需要做任何修改。
依赖注入的种类
依赖注入主要通过初始化器注入、属性注入、方法注入、接口注入等方式来进行注入。
初始化器注入
初始化器注入就是通过初始化方法的参数来给对象提供依赖。初始化器注入是最常用的注入方式，它简单直观，当一个对象依赖的对象的生命周期和对象自身相同时，使用初始化器注入是最好的方式。
class ClientObject {
private var dependencyObject: DependencyObject
init(dependencyObject: DependencyObject) {
self.dependencyObject = dependencyObject
}
}
属性注入
属性注入是通过对象的公开属性来给对象提供依赖，也可以叫 setter 注入。一般在无法使用初始化器注入时（例如使用了 Storyboard），或者依赖对象的生命周期小于对象时使用。
public class ClientObject {
public var dependencyObject: DependencyObject
}
let client = ClientObject()
client.dependencyObject = DefaultDependencyObject()
方法注入
方法注入的方式是对象需要实现一个接口，这个接口中声明了能给对象提供依赖的方法。注入器通过调用这个方法来给对象提供依赖。方法注入也可以叫接口注入。
protocol DependencyObjectProvider {
func dependencyObject() -> DependencyObject
}
有时客户方只在某些特定的条件下才需要使用依赖，这时可以用方法注入，客户方仅仅在需要使用依赖的时候才会去调用方法来创建依赖对象，这样避免了客户方在不使用依赖的时候依赖对象也被创建出来占用内存空间的问题。这一点也可以通过注入一个代码块来实现：
init(dependencyBuilder: () -> DependencyObject) {
self.dependencyBuilder = dependencyBuilder
}
依赖注入容器
依赖注入要求对象的依赖在对象外部创建并通过某种方式注入到对象中。如果每次创建对象时都去创建一遍对象的依赖，会让代码变得重复和复杂，当对象的依赖调整时，每个地方都需要做改动。因此通常使用依赖注入时，也需要一个依赖注入容器（Dependency Injection Container）。
依赖注入容器用来统一地管理依赖对象的创建和生命周期，也可以根据需要给对象注入依赖。
依赖注入容器要提供以下的功能：
- 注册（Register）：容器需要知道对于一个特定的类型，应该怎样构建它的依赖，容器内会保存类型-依赖的映射信息，并提供接口可以向容器添加这个类型信息，这个操作就是注册。
- 解析（Resolve）：当使用依赖注入容器时，就不需要手动创建依赖了，而是让容器帮我们做这件事情。容器需要提供一个方法来根据类型得到一个对象，容器会创建好这个对象的所有依赖，调用方即可无需关心依赖，直接使用这个对象即可。
- 处置（Dispose）：容器需要管理依赖对象的生命周期，并在依赖对象的生命周期结束时处置它。
实现一个简单的依赖注入容器
有很多第三方依赖注入框架实现了依赖注入的功能，例如 Swift 语言的 Swinject。我们也可以自己实现一个依赖注入容器。
按照依赖注入容器的定义，并借助 Swift 的泛型和协议，可以定义以下协议：
protocol DIContainer {
func register<Component>(type: Component.Type, component: Any)
func resolve<Component>(type: Component.Type) -> Component?
}
具体实现如下：
final class DefaultDIContainer: DIContainer {
static let shared = DefaultDIContainer()
private init() {}
var components: [String: Any] = [:]
func register<Component>(type: Component.Type, component: Any) {
components["\(type)"] = component
}
func resolve<Component>(type: Component.Type) -> Component? {
return components["\(type)"] as? Component
}
}
有了这个 DIContainer，在使用时可以选择两种方式，一种是在外部 resolve 对象并注入。
let object = DIContaienr.shared.resolve(Data.self) let viewModel = ViewModel(dependencyObject: object)
一种是在初始化方法的参数默认值中 resolve：
class ViewModel {
init(dependencyObject: DependencyObject = DIContainer.shared.resolve(Data.self))
self.dependencyObject = dependencyObject
}
这两种方式各有一些使用场景，可以根据具体情况选用。
以上的 DIContainer 只是一个简单的实现，结合具体需求，可以添加上线程安全、Storyboard 注入，自动解析等功能，可参考 Swinject。
总结
依赖注入在很多领域都是常见的设计模式，例如 Java Spring 等，无论做哪个方向的开发，依赖注入都是一定要掌握的。在合适的时候使用依赖注入，可以让代码解耦，提高代码的可测试性、可扩展性。
参考资料