Swift 中风味各异的依赖注入_Swift

Swift 中风味各异的依赖注入

前言

在之前的文章中，我们看了一些使用依赖注入的不同方法，以实现Swift应用中更多的解耦和可测试架构。例如，在Swift中使用工厂的依赖注入[1]中把依赖注入和工厂模式结合起来，以及在Swift中避免使用单例[2] 中利用依赖注入取代单利。

到目前为止，我的大部分文章和例子都使用了基于初始化器的依赖注入。然而，就像大多数编程技术一样，依赖注入有多种“风味(Flavors)”，每一种都有自己的优点和缺点。本周，让我们来看看三种不同方式的依赖注入，以及它们如何在Swift中使用。

基于初始化器

让我们先快速回顾一下最常见的依赖注入方式——基于初始化器的依赖注入，即对象在被初始化时应该被赋予它所需要的依赖关系。这种方式的最大好处是，它保证我们的对象拥有它们所需要的一切，以便立即开展工作。

假设我们正在构建一个从磁盘上加载文件的FileLoader。为了做到这一点，它使用了两个依赖项——一个是系统提供的FileManager的实例，另一个是Cache。使用基于初始化器的依赖注入，可以这样实现:

class FileLoader { private let fileManager: FileManager private let cache: Cache init(fileManager: FileManager = .default, cache: Cache = .init()) { self.fileManager = fileManager self.cache = cache }
}

注意上面是如何使用默认参数的，以避免在使用单例或新实例时总是创建依赖关系。这使我们能够在生产代码中使用FileLoader()简单地创建一个文件加载器，同时仍然能够通过在测试代码中注入模拟数据或显式实例进行测试。

基于属性

虽然基于初始化器的依赖注入通常很适合你自己的自定义类，但有时当你必须从系统类继承时，它就有点难用了。一个例子是在构建视图控制器时，特别是当你使用 XIBs 或 Storyboards 来定义它们时，因为这样你就无法再控制你的类的初始化器了。

对于这些类型的情况，基于属性的依赖注入可以是一个很好的选择。与其在对象的初始化器中注入对象的依赖关系，不如在之后简单地将其分配。这种依赖注入的方式也可以帮助你减少模板文件，特别是当有一个好的默认值不一定需要注入的时候。

让我们来看看另一个例子——在这个例子中，我们要建立一个PhotoEditorViewController，让用户编辑他们库中的一张照片。为了发挥作用，这个视图控制器需要一个系统提供的PHPhotoLibrary类的实例(它是一个单例)，以及一个我们自己的PhotoEditorEngine类的实例。为了在没有自定义初始化器的情况下实现依赖性注入，我们可以创建两个都有默认值的可变属性，就像这样:

class PhotoEditorViewController: UIViewController { var library: PhotoLibrary = PHPhotoLibrary.shared() var engine = PhotoEditorEngine()
}

请注意 *"通过 3 个简单的步骤测试使用了系统单例的 Swift 代码"*中的技术是如何通过使用协议来为系统照片库类提供一个更抽象的PhotoLibrary接口。这将使测试和数据模拟变得更加容易!

上述做法的好处是，我们仍然可以很容易地在测试中注入模拟数据，只需重新分配视图控制器的属性：

class PhotoEditorViewControllerTests: XCTestCase { func testApplyingBlackAndWhiteFilter() { let viewController = PhotoEditorViewController()
        // 分配一个模拟照片库以完全控制里面存储了哪些照片 let library = PhotoLibraryMock() library.photos = [TestPhotoFactory.photoWithColor(.red)] viewController.library = library // 运行我们的测试命令 viewController.selectPhoto(atIndex: 0) viewController.apply(filter: .blackAndWhite) viewController.savePhoto()
        // 断言结果是正确的 XCTAssertTrue(photoIsBlackAndWhite(library.photos[0]))
    }
}

基于参数

最后，让我们看一下基于参数的依赖注入。当你想轻松地使遗留代码变得更容易测试且不必过多地改变其现有结构时，这种类型特别有用。

很多时候，我们只需要一个特定的依赖关系一次，或者我们只需要在某些条件下模拟它。我们不需要改变对象的初始化器或将属性暴露为可变的(这并不总是一个好方式)，而是可以开放某个API来接受一个依赖关系作为参数。

让我们来看看一个NoteManager类，它是一个记事应用程序的一部分。它的工作是管理用户所写的所有笔记，并提供一个API用于根据查询来搜索笔记。由于这是一个可能需要一段时间的操作(如果用户有很多笔记的话，这是很有可能的)，我们通常在一个后台队列中执行，像这样:

class NoteManager { func loadNotes(matching query: String, completionHandler: @escaping ([Note]) -> Void) { DispatchQueue.global(qos: .userInitiated).async { let database = self.loadDatabase() let notes = database.filter { note in return note.matches(query: query)
            } completionHandler(notes)
        }
    }
}

虽然上述方法对我们的生产代码来说是一个很好的解决方案，但在测试中，我们通常希望尽可能地避免异步代码和并行性，以避免片状现象。虽然使用初始化器或基于属性的依赖注入来指定NoteManager应始终使用的显式队列会很好，但这可能需要对类进行大的修改，而我们现在还不能/不愿意这样做。

这就是基于参数的依赖性注入的作用。与其重构我们的整个类，不如直接注入要在哪个队列上运行loadNotes操作：

class NoteManager { func loadNotes(matching query: String, on queue: DispatchQueue = .global(qos: .userInitiated), completionHandler: @escaping ([Note]) -> Void) { queue.async { let database = self.loadDatabase() let notes = database.filter { note in return note.matches(query: query)
            } completionHandler(notes)
        }
    }
}

这使我们能够在测试代码中轻松地使用一个自定义队列，我们可以在上面等待。这几乎可以让我们在测试中把上述API变成一个同步的API，这让事情变得更容易和更可预测。

基于参数的依赖注入的另一个用例是当你想测试静态API的时候。对于静态API，我们没有初始化器，而且我们最好也不要静态地保持任何状态，所以基于参数的依赖注入成为一个很好的选择。让我们看一个当前依赖单例的静态 MessageSender 类：

class MessageSender { static func send(_ message: Message, to user: User) throws { Database.shared.insert(message) let data: Data = try wrap(message) let endpoint = Endpoint.sendMessage(to: user) NetworkManager.shared.post(data, to: endpoint.url)
    }
}

虽然理想的长期解决方案可能是重构MessageSender，使其成为非静态的，并在其使用的任何地方正确注入，但为了方便测试(例如，为了重现/验证一个错误)，我们可以简单地将其依赖性作为参数注入，而不是依赖单例：

class MessageSender { static func send(_ message: Message, to user: User, database: Database = .shared, networkManager: NetworkManager = .shared) throws { database.insert(message) let data: Data = try wrap(message) let endpoint = Endpoint.sendMessage(to: user) networkManager.post(data, to: endpoint.url)
    }
}