这并不是说单体本身是坏的，而是GoF设计模式是坏的。唯一真正有效的论点是，GoF设计模型不适合测试，尤其是在并行运行测试的情况下。

只要在代码中应用以下方法，使用类的单个实例就是有效的构造：

确保将用作单例的类实现了一个接口。这允许使用相同的接口实现存根或模拟确保Singleton是线程安全的。这是给的。单例应该是简单的，而不是过于复杂。在应用程序的运行时，如果需要将单例传递给给定对象，请使用构建该对象的类工厂，并让类工厂将单例实例传递给需要它的类。在测试期间，为了确保确定性行为，将单例类创建为单独的实例，作为实际类本身或实现其行为的存根/模拟，并将其原样传递给需要它的类。不要使用在测试期间创建需要单例的被测对象的类因子，因为它将传递其单个全局实例，这违背了目的。

我们已经在我们的解决方案中使用了Singleton，并取得了巨大的成功，这些成功是可测试的，确保了并行测试运行流中的确定性行为。

单身者解决了一个（而且只有一个）问题。

资源争夺。

如果你有一些资源

（1） 只能有一个实例，并且

（2） 您需要管理单个实例，

你需要一个单身汉。

例子不多。日志文件是最大的文件。您不想只放弃一个日志文件。您希望正确刷新、同步和关闭它。这是必须管理的单个共享资源的示例。

你很少需要单身汉。他们之所以不好，是因为他们觉得自己是一个全球性的人，而且他们是GoF设计模式书的全额付费成员。

当你认为你需要一个全局，你可能犯了一个可怕的设计错误。

单线态的问题是范围增加，因此耦合的问题。不可否认，在某些情况下，您确实需要访问单个实例，并且可以通过其他方式实现。

我现在更喜欢围绕控制反转（IoC）容器进行设计，并允许容器控制生命周期。这为依赖于实例的类提供了好处，使它们不知道存在单个实例的事实。将来可以更改单例的生存期。我最近遇到的一个例子是从单线程到多线程的简单调整。

FWIW，如果你尝试单元测试它时它是一个PIA，那么当你尝试调试、修复或增强它时，它就会变成PIA。

首先，一个类及其合作者应该首先实现其预期目的，而不是专注于依赖对象。生命周期管理（当实例被创建并且超出范围时）不应该是类责任的一部分。对此，公认的最佳实践是创建或配置一个新组件，以使用依赖注入来管理依赖关系。

通常，软件变得更加复杂，所以有多个状态不同的Singleton类的独立实例是有意义的。在这种情况下，提交代码来简单地抓取单例是错误的。使用Singleton.getInstance（）可能适用于小型简单系统，但当需要同一类的不同实例时，它无法工作/扩展。

任何类都不应该被认为是一个单独的类，而应该是它的用法或如何使用它来配置依赖项的应用程序。对于快速而令人讨厌的应用程序来说，这并不重要——只是简单的硬编码表示文件路径不重要，但对于更大的应用程序，需要使用DI以更合适的方式分解和管理这些依赖关系。

单例在测试中引起的问题是其硬编码的单一用例/环境的症状。测试套件和许多测试都是单独的，并且是独立的，与单例硬编码不兼容。

Chris Reath最近在《无注释编码》杂志上发表的关于此主题的文章。

注意：无注释编码不再有效。但是，链接到的文章已被其他用户克隆。

Link

单身汉——反模式！马克·拉德福德（Mark Radford）的《过载杂志》（Overload Journal#57–2003年10月）很好地解释了为什么辛格尔顿被视为反模式。本文还讨论了替代Singleton的两种替代设计方法。