5

我有一个应用程序，它在许多应用程序的方法和类中使用了大约 11 个不同的 Singleton 实例；它已经失控了，我想用依赖注入替换所有这些，比如 Typhoon。但是，我找不到任何文档、示例或提及如何用依赖注入替换单例，包括 Typhoon。例如，我是否使用多个 Typhoon 实例，将每个单例替换为 Typhoon 实例？

4

1 回答 1

9

编辑： 朝圣者是台风的官方 Swift 继任者！！

台风创造者在这里。是的，依赖注入的用途之一是提供单例的好处而没有缺点。但是您不一定需要一个库来应用依赖注入模式并替换您的单例。事实上，它有助于理解模式，首先看看如何在没有框架的情况下实现它：

好莱坞原则：不要打电话给我们，我们会打电话给你

高级类，如视图控制器，会交给协作者来完成他们的工作。正如你所提到的，你有大约 11 个。现在有两种方法可以将您的班级与合作者联系起来：

寻找（呼叫）合作者：

initWithNibName:(NSString *)nibName bundle:(NSBundle *)bundle 
{
    self = [super initWithNibName:nibname bundle:bundle];
    if (self) {
        _serviceClient = [MyServiceClient sharedInstance];
    }
}

上述方法有效，但效果不佳，因为：

  • 如果你想提供一个替代实现，那么你必须去改变每个使用它的类。
  • 它使编写干净的单元或集成测试变得困难。您必须查看类的内部结构（玻璃盒测试），而不是关注外部接口契约（黑盒测试）。
  • 它提供了过于紧密的耦合，从而导致内聚性差。

替代方案：

只需通过 init 方法或属性将协作者传入。

initWitServiceClient:(id<ServiceClient>)serviceClient
{
    self = [super initWithNibName:@"MyNib" bundle:[NSBundle mainBundle]; 
    if (self) {
        _serviceClient = serviceClient;
    }
}

这和刚才有什么不同。. . 传递论点？

而不是硬连接合作者，而是将其作为参数传递。但是现在下一节课是硬连线的！所以你一直这样做，直到你有一个顶级的程序集类，它知道如何从各个部分构建你的视图控制器（和其他类）。如果你这样做：

  • 对每个单例的所有引用都指向一个地方。因此，用兼容的实现替换您的一个单例只需要更改一行代码。同样，您已经封装了此类的配置。
  • 它很容易为您的类编写单元和集成测试。在后一种情况下，您可以为另一个组件修补一个组件。这可以克服集成式测试的两个缺点。第一个是很难将系统置于测试场景所需的状态，第二个是它们可能会产生不需要的副作用。同时，纯单元测试也被简化了，因为它现在很容易看到依赖契约并为这些传递模拟或存根。
  • 课程清楚地记录了他们的“接缝”以及他们将委派给哪些重要合作者以执行他们的任务。这导致“高凝聚力”。

现在使用台风：

每个普通应用程序都会保留一个 Typhoon 实例。它将容纳您的单身人士。

如果在学习了上述材料后您有更具体的问题，我们很乐意为您提供帮助。

于 2014-12-31T03:49:12.070 回答