依赖注入(如Typhoon )可以替代多个单点吗？

Question

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

Answer 1

编辑： 朝圣者是台风的官方接班人！

这里是台风制造者。是的，依赖注入的一个用途是提供单例的好处，而不是缺点。但是，您不一定需要一个库来应用依赖项注入模式并替换您的单例。实际上，通过查看如何在不使用框架的情况下实现它，了解这种模式是有帮助的：

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

高级类，比如视图控制器，让协作者来完成他们的工作。正如你所提到的，你有大约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实例。它会容纳你的单身人士。

• 声明程序集定义了你的单身汉。给他们单例范围。
• 使用褶皱集成引导应用程序中的台风。台风的充分的应用程序显示如何做到这一点。
• 定义定义和注入视图控制器的程序集。台风样本应用展示了如何做到这一点。或者使用自动布线宏。如果你用的是故事板的话，这些都能很好的工作。

如果在学习了以上资料后，您有一个更具体的问题，我们将非常乐意帮助您。