我有一个简单的问题，我甚至不确定它是否有答案，但让我们尝试。
我使用C++进行编码，并使用依赖项注入(inject)来避免全局状态。这工作得很好，而且我不会经常出现意外/未定义的行为。
但是我意识到，随着项目的发展，我正在编写许多我认为很简单的代码。更糟糕的是:事实比实际的代码更多，这使得有时很难理解。
没有什么比一个好的例子更好了，让我们开始吧:
我有一个名为TimeFactory的类，它创建Time对象。
有关更多详细信息(不确定是否相关):时间对象非常复杂，因为时间可以具有不同的格式，并且它们之间的转换既不是线性的也不是简单的。每个“时间”都包含一个同步器来处理转换，并确保它们具有相同的，正确初始化的同步器，我使用TimeFactory。 TimeFactory仅具有一个实例，并且是应用程序范围的，因此它符合单例的条件，但是由于它是可变的，因此我不想将其设为单例
在我的应用中，很多类都需要创建Time对象。有时，这些类是深层嵌套的。
假设我有一个类A，其中包含类B的实例，依此类推，直到类D。类D需要创建Time对象。
在我的幼稚实现中，我将TimeFactory传递给类A的构造函数，然后将其传递给类B的构造函数，依此类推，直到类D。
现在，假设我有几个类(如TimeFactory)和几个类层次结构(如上一个类):我失去了使用依赖注入(inject)的所有灵活性和可读性。
我开始怀疑我的应用程序中是否没有主要的设计缺陷...
还是使用依赖注入(inject)是必要的邪恶？
你怎么看 ？
最佳答案
这是依赖注入(inject)的常见误用。除非类A直接使用TimeFactory，否则它将永远不会看到，了解或访问TimeFactory。 D实例应使用TimeFactory构造。然后，应该使用刚刚构建的D实例来构建C实例。然后是B与C，最后是A与B。现在，您有了一个A实例，该实例间接拥有一个可以访问TimeFactory的D实例，而A实例从未看到TimeFactory直接传递给它。
MiškoHevery在this video中谈到了这一点。
关于c++ - 依赖注入(inject);减少样板代码的良好做法，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/11813950/