依赖注入iOS让我们变得简单

依赖注入：拆分此英语术语以获取更简便的方法

依赖-您所依赖的东西

注入-用于注入东西

所以依赖注入意味着注入需要的依赖而不是创建它 或者我们也可以说将依赖注入到对象中，而不是负责创建对象依赖的任务 。

或某些怪胎将其定义为为对象提供实例变量，而不是在对象中创建实例变量。 😛

让我们以一个例子来获得更清晰的图像：

在这里的例子

关键是MyViewController负责创建Service实例。这意味着MyViewController类不仅了解Service类的行为。 它还知道其实例化。

现在在下一个DI示例中，我们在创建对象时将Service实例注入MyViewController实例。 尽管最终结果可能看起来与上面的示例相同，但事实并非如此。 通过从外部注入Service ， MyViewController不知道如何实例化Service 。

简单来说，这就是依赖注入。

通常，依赖注入被认为是3种类型：

通过初始化程序进行依赖注入：

也称为基于构造函数，最优选的 是在初始化期间在构造函数 （构造函数） 中传递依赖项。在初始化程序中，通过将依赖项的属性声明为常量（使用let）来使基于DI的依赖项不可变。让它在整个客户的一生中都发生变化。

因为要求我们在初始化期间将服务作为参数传递，所以指定的初始化程序清楚地显示了DataManager类的依赖项。

通过属性进行依赖注入：

在类中声明的Internal或Public属性也可以用于将依赖项注入到类对象中。 这似乎很方便，但是它增加了一个漏洞，因为可以修改或替换依赖关系。 换句话说，依赖关系不是一成不变的。

使用serviceManager属性将服务依赖项传递给类MyViewController的viewController实例。

通过方法进行依赖注入：

依赖项也可以在需要时注入。 通过声明一个将依赖项作为参数接受的方法，这很容易做到。 在下面的示例中，该服务不是DataManager类的属性。 而是将服务作为方法的参数注入。

即使DataManager类失去了对依赖项，服务的控制，这种类型的依赖项注入也带来了灵活性。

为什么要使用依赖注射：-

测试：依赖注入使开发人员可以用模拟对象替换对象的依赖关系，从而使单元测试更易于设置和隔离行为。

透明度：通过注入对象的依赖关系，类或结构的职责和要求变得更加清晰和透明。

松耦合：协议和依赖注入的使用可以减少项目中的耦合。 协议在Swift中非常有用且用途广泛。 这是协议真正发挥作用的一种情况。

关注分离 ：依赖注入严格地分离了对类的关注。如果类不负责实例化依赖实例，则它不需要知道如何做到这一点。

即使它与依赖关系的行为有关，但也不应与其实例化有关。

我们得出结论：

依赖注入是您在项目中可能已经在使用的东西，它的好处确实使结构易于理解，可重用，可测试和可维护，因此不要再键入几行代码，而是开始使用聪明的想法。

快乐编码

保持冷静和智能代码