我正在尝试编写使用依赖注入的代码，以允许模拟并具有更清晰、更明确的设计。
我经常发现自己遇到了一个我认为很常见的特定问题，但我还没有在网上找到任何可以帮助我克服它的东西。
问题是对象 A 依赖于 B，B 依赖于 C，C 依赖于 D，等等，在一个可能有许多链接的链中。
似乎要在这里练习依赖注入，A 必须在其构造函数中请求 B、C、D 等（或 BFactory、CFactory 等创建它们所依赖的实例的对象）。为了论证，我假设依赖项不是可选的或仅限于特定的方法，这使得 setter 注入或方法参数注入不合适。
这向我表明，依赖对象的长链是一种反模式。在抽象意义上，它与箭头反模式有一些共同点。依赖对象的长链形成一个箭头形的序列图。
那么，也许我应该避免这种做法，并遵循“Python 之禅”中“平面优于嵌套”的建议。这表明主程序创建两个或三个对象，它们协作并产生返回给主程序的结果，然后创建另外两个或三个对象来完成下一阶段的工作，依此类推。
我觉得这种代码很容易理解和调试，也很容易进行依赖注入。但这似乎违背了Tell Don't Ask原则，并且使主程序过于肥大。我喜欢 main 如此小且如此明显以至于不需要单元测试的想法。Tell Don't Ask 对我说，如果一切都以 A 开头并以 A 结尾，那么这是 A 的责任。假设 A 是一位被计费的客户，该客户拥有开始计费流程所需的数据以及发票需要在最后发送到的电子邮件地址。然后似乎 A 应该自己完成工作（main 可以调用 Customer.billYourself()），而不是通过向 main 提供一堆发票和一个电子邮件地址将责任交还给 main。
那么，我应该避免依赖链，使 DI 更容易，还是因为 Tell Don't Ask 而拥抱它们？