你能在需要单例的地方使用依赖注入吗？答案

【问题标题】：Can you use dependency injection everywhere a singleton is needed?你能在需要单例的地方使用依赖注入吗？
【发布时间】：2010-07-04 08:31:01
【问题描述】：

这听起来像是一个愚蠢的问题，但是 DI 可以在需要 Singleton 的任何地方使用吗？或者是否存在单例更有意义的用例？我的一位教授说，在少数但有效的情况下，单身人士“足够好”，但我对此并不满意：-/。

【问题讨论】：

标签： design-patterns dependency-injection singleton

【解决方案1】：

DI 中的一个主题是要注入的对象的生命周期。示例生命周期包括 Singleton 以及 Transient、HttpContext、ThreadLocal、Custom 等……因此，当使用 DI 时，您可以指定一个对象为 Singleton 生命周期，可能是在应用程序启动时填充的配置类。作为单身人士，这似乎是一个不错的课程。

单例模式是一种强大的模式，但与所有设计模式一样，如果以不正确的方式使用它们可能弊大于利。 DI 和 Singleton 的避免也带来了更好的可测试性。

现在干杯，

安德鲁

【讨论】：

【解决方案2】：

单例是一种模式。它经常出现在 DI 容器中或作为static API 出现。我假设您指的是static 风格。

通过static 成员暴露的对象为消费者提供了最低可能的摩擦；这就是它们如此吸引人的原因。依赖注入以不同的方式解决了相同的问题（对象访问）。对于 DI，依赖项的生命周期是一个配置细节，而不是固有的事实。

这是我解决此问题的另一个答案：

Dependency Injection & Singleton Design pattern

【讨论】：

【解决方案3】：

只要有可能，我肯定会对单例对象使用依赖注入。即使除了对象的一个特定实现之外，您不太可能注入任何东西，使用注入几乎没有缺点，而且有很多潜在的好处。根据我的经验，依赖注入使阅读代码的人更容易理解依赖关系，使代码更容易重构，提高可测试性，并且通常会缩短构建时间。

也就是说，我遇到了理想情况下希望使用注入但选择不使用的代码。以下是一些示例。

我正在处理一个我无法轻易更改的 API。
我正在编写代码，如果我要求客户端注入一些他们不应该知道的东西，API 会显得很奇怪。某些静态实用程序库是这样，例如解析字符串的函数，其中我有一个我不希望我的用户知道的辅助对象。不过，我通常会尽量避免这种情况。
我正在编写我将要丢弃的实验代码。在这种情况下，我通常会采取捷径让某些东西快速运行，并理解以后应该删除或重构代码。

如果您还没有使用过它们，您可能需要查看依赖注入框架。我很高兴在 Java 代码中使用 Google Guice。

【讨论】：

+1 我直到现在还没有使用 DI，但是在项目中使用 Singletons 来全局可访问的配置对象，结果一团糟，因为只有六分之二的人可以真正解释类会结合在一起（即它们如何相互依赖）。