Swift中的依赖注入

轻松启用验收测试

在使用OOP范式开发应用程序时，您将意识到，如果您希望能够测试软件，则需要使用IoC原理。 通常，为了实现这一点，我们使用依赖项注入模式，该模式包括为每个类提供所需的依赖项。

在本文中，我将展示一种在Swift中放置此模式的方法，以便轻松模拟图形的某些依赖关系。

即使您不关心测试应用程序，我也建议您在代码中应用此原则，但随着项目规模的扩大，您将不胜感激。

在构造函数中使用默认值

在Swift中，我们可以通过在构造函数中使用默认值来实现混蛋注入。

容易吧？ 起初，这似乎是一个好主意，因为它提高了可测试性，并且易于安装，但是确实存在一些问题。 此解决方案的主要问题是您与依赖项的默认构造函数紧密相关。 想象一下，您想编写一个UI测试，在其中使用test double模拟HTTP响应。 在这种情况下，您将需要提供此UIViewController的所有依赖关系 ，因为您不能再使用默认构造函数。 这是浪费时间，不是吗？

浸洗

由于上面讨论的问题，我决定尝试一些替代方法，例如Dip或Swinject。 这两个框架实际上非常相似。 它们是依赖项容器，您可以在其中注册如何使用lambda解决依赖项。 在高层，他们的工作是将这些lambda存储在字典中，并在需要实例化服务时使用它。 因此，要解决该问题，您只需要覆盖要用test double替换的所有内容即可。

但是，这些框架有一些缺点，例如：

• 依赖关系图是在运行时构建的，因此，如果您忘记注册如何解决依赖关系，应用程序将在运行时崩溃。
• 由于您需要在使用依赖项之前先注册它们，因此如果在启动时加载应用程序，则将花费更长的时间。
• 解决依赖项时，您需要使用强制解包（Swinject）或尝试（Dip）。
• 在我看来，最糟糕的问题是，如果您需要在运行时传递参数，则不会键入这些参数，并且不会自动完成。 犯错很容易，只需更改依赖关系的顺序，应用程序就会在运行时崩溃。

因此，我决定不使用它们，而是找到一个适合我的用例的解决方案，而又不影响性能，又不会失去由于Swift编译器而获得的安全性。

拟议的解决方案

我建议的解决方案具有您将喜欢的以下功能：

• 输入了解决依赖关系所需的参数，因此您不会出错。
• 如果忘记定义如何实例化对象，则该应用将无法编译。
• 该应用程序的性能不受影响。 您无需注册如何在运行时解析依赖关系。
• 处理可选值并不难，因为它可以在Swinject或Dip中进行。
• 您不需要使用任何外部库。 依赖项注入器会影响整个代码库，并且与第三方库的依赖项存在风险。

为了实现它，该解决方案使用了一些Swift功能，例如类型推断和协议扩展。 让我们看一个简单的例子。

想象一下代表超级英雄的下一个结构：

我们可以使用为您提供超级英雄实例并使用默认实现对其进行扩展的功能来定义协议。 我们将其命名为SuperHeroAssembler ：

现在我们可以使用它来解析SuperHero实例：

以及如何在测试中模拟它？ 好吧，这确实很容易，我们只需要创建一个符合SuperHeroAssembler的新类，但具有不同的resolve函数即可。 让我们看看如何实现它：

也许通过这样一个简单的示例，您看不到任何优势，但是如果使用得当，此想法将非常有用。 让我们看一个更详细的用例的例子，看看它是如何工作的。

它如何与用例一起工作？

想象一个屏幕，您需要在其中显示给定用户的所有联系人。 联系人来自网络，我们希望能够在验收测试中使用双重测试。

为此，我们使用以下类：

为了定义如何解决依赖关系，我们将针对该用例使用一个汇编器，我将其称为ContactsSceneAssembler 。 在此汇编器中，我们将具有一个能够解析所需的每种类型的函数。

如您所见，我们可以（并且必须）重用汇编器本身来解决依赖关系。 另一个很棒的事情是，我们在运行时知道函数的输入参数及其类型。 因此，当您编写自动完成时，将可以完成大部分工作：D。

现在，创建一个ContactsListViewController 我们只需要使用汇编程序来使用给定的用户来解决它。

正如我们在第一个示例中看到的那样，可以很容易地使用测试双NetworkContactsDataSource代替NetworkContactsDataSource 。 您只需要创建一个汇编程序，即可在其中将ContactsDataSource解析为测试double对象：