依赖注入和链接委托调用

可测试的代码很棒。 即使您实际上没有编写任何单元测试，也可以使您的生活更轻松。 您将获得易于维护和重构的模块化结构。 到处都使用单例并不是可测试的代码。 我们经常听到人们对此表示同意，但是随后他们提出了“委托地狱”的论点。

我需要从应用程序的多层一直发送一些数据。 您是否建议我将其注入所有这些对象或使用十二个链接的委托调用？ 啊!

好吧，让我们一起看看。

问题：

在这里使用共享实例并不能使我们的代码更具可测试性，清晰性或结构性，但是很容易实现：

解决方案1：共享实例

似乎链委托调用是这里唯一的选择，但是这种解决方案看起来很丑陋。 首先，链接的委托呼叫非常脆弱-您可以轻松地忘记一个。 其次，所有与主题菜单无关的对象现在也知道那里发生了某些事情。

解决方案2：链接的委托呼叫

还有其他解决方案吗？ 当然！

现在的问题是，我们正在将构造责任与业务逻辑责任混在一起。 当我们需要一个对象时，我们只需在我们的类中内联实例化它即可。

我们的调用图与实例化图几乎相同。 让我们尝试将它们分开！

想象一下，应用程序下面的某些层需要一个数据库才能工作。 您可以清楚地说明此依赖性，并且您的层会在构造函数中请求数据库。

现在，它上面的一层不会说“我需要一个数据库才能将它传递给下面的层”，而是说“我需要下面的一层”！ 上面的层没有关于数据库的线索。 如果您应用中某处的某个对象需要数据库，则并不意味着您需要在整个类层次结构中传递该数据库。

这是这样的：

解决方案3：工厂

最后，如果您还没有看过，请观看MiškoHevery的这场“清洁代码”演讲。