OOP - 嵌套对象依赖关系的长链是反模式吗？

Question

我正在尝试编写使用依赖注入(inject)的代码，既允许模拟，又具有更清晰、更明确的设计。

我经常发现自己遇到了一个我认为很常见的特定问题，但我还没有在网上找到任何可以帮助我克服它的东西。

问题在于对象 A 依赖于 B，B 依赖于 C，C 依赖于 D，等等，在一条可能有很多链接的链中。

似乎要在这里练习依赖注入(inject)，A 必须在其构造函数中请求 B、C、D 等(或者对于创建它们所依赖的实例的对象，请求 BFactory、CFactory 等) 。为了论证，我假设依赖项不是可选的或仅限于特定的方法，使得 setter 注入(inject)或方法参数注入(inject)不合适。

这对我来说表明依赖对象的长链是一种反模式。从抽象意义上讲，它与箭头反模式有一些共同点。依赖对象的长链形成箭头形序列图。

也许，我应该避免这种做法，并遵循“Python之禅”中的建议“扁平比嵌套更好”。这表明主程序创建两个或三个对象，它们协作并产生返回到主程序的结果，然后主程序创建另外两个或三个对象来完成下一阶段的工作，依此类推。

我感觉这种代码很容易理解和调试，并且使依赖注入(inject)变得容易。但这似乎违背了“告诉不要问”的原则，并且使主程序变得过于臃肿。我喜欢 main 如此小且如此明显以至于不需要单元测试的想法。 《告诉不要问》对我说，如果一切都以A开始并以A结束，那么这是A的责任。假设 A 是正在计费的客户，并且该客户拥有开始计费流程所需的数据以及最终需要将发票发送到的电子邮件地址。那么看来 A 应该自己完成工作(main 可以只调用 Customer.billYourself())，而不是通过给 main 一堆发票和一个电子邮件地址来将责任交还给 main。

那么，我应该避免依赖链，让 DI 更容易，还是因为“告诉不要问”而拥抱它们？

Answer 1

类有很多依赖关系。这只是生活的一个事实。但这些类如何相互依赖决定了整个事情的好坏。

您应该阅读 Stable Dependencies Principle 。如果遵循此规则，依赖项的数量就不应该成为问题:

THE DEPENDENCIES BETWEEN PACKAGES IN A DESIGN SHOULD BE IN THE DIRECTION OF THE STABILITY OF THE PACKAGES. A PACKAGE SHOULD ONLY DEPEND UPON PACKAGES THAT ARE MORE STABLE THAN IT IS.

有好的依赖关系，也有坏的依赖关系:

Thus, we can say that a “Good Dependency” is a dependency upon something with low volatility. The less volatile the target of the dependency, the more “Good” the dependency is. By the same token a “Bad Dependency” is a dependency upon something that is volatile. The more volatile the target of the dependency is, the more “Bad” the dependency is.

构建您的应用程序以具有良好的依赖性。