我正在尝试编写使用依赖注入的代码，既允许进行模拟，又可以使用更清晰，更明确的设计。
我经常发现自己遇到了一个我认为常见的特定问题，但我还没有在网上找到任何帮助我克服它的东西。
问题在于对象A依赖于B，B依赖于C，C依赖于D，依此类推，链中可能包含许多链接。
似乎在这里练习依赖注入，A必须在其构造函数中要求B，C，D等等（或者对于创建它们所依赖的实例的对象的BFactory，CFactory等） 。我假设为了论证，依赖关系不是可选的或对特定方法有所依赖，使得setter注入或方法参数注入不合适。
这向我表明，依赖对象的长链是反模式。从抽象的角度来看，它与箭头反模式有一些共同之处。长链的依赖对象形成一个箭头形的序列图。
也许，那么，我应该避免这种做法，并遵循“禅宗的Python”中的建议，即“扁平比嵌套好”。这表明主程序创建两个或三个对象的设计，这些对象协作并产生返回主程序的结果，然后创建另外两个或三个以完成工作的下一个阶段，依此类推。
我觉得这种代码很容易理解和调试，并且易于依赖注入。但它似乎违反了Tell Do Not Ask原则，并使主程序太胖了。我喜欢主要是如此小而且非常明显以至于不需要单元测试的想法。并告诉不要问我告诉我，如果一切都以A开头并以A结尾，那么这是A的责任。假设A是被计费的客户，并且客户拥有开始计费过程所需的数据以及发票需要在最后发送到的电子邮件地址。然后似乎A应该自己完成工作（main可以只调用Customer.billYourself（）），而不是通过给main发送一堆发票和一个电子邮件地址来将reponsibility交给main。
那么，我是否应该避免依赖链，使DI更容易，或者因为Tell Do not Ask而拥抱它们？
答案 0 :(得分：4)
类具有许多依赖项。这只是生活中的一个事实。但是这些类如何相互依赖会使整个事情变得好或坏。
您应该阅读Stable Dependencies Principle。如果您遵循此规则，则依赖项的数量不应成为问题：
设计中的包装之间的相关性应该在 对包装稳定性的指导。包装应仅依赖于比以往更稳定的包装。
存在良好的依赖关系，并且存在错误的依赖关系：
因此，我们可以说“良好依赖”是一种依赖 波动性低的东西。目标的波动性较小 依赖性，依赖性越“好”。同样的道理 “坏依赖”是对易失性事物的依赖。该 依赖的目标越不稳定，越“坏” 依赖是。
构建您的应用以保持良好的依赖关系。