一些代码势利者看不起他们，认为他们只是一个荣耀的全球人。就像许多人讨厌goto语句一样，也有其他人讨厌使用全局的想法。我见过几位开发人员为了避免全局性而竭尽全力，因为他们认为使用全局性是失败的承认。奇怪但真实。

在实践中，Singleton模式只是一种编程技术，它是概念工具包的有用部分。有时你可能会发现它是理想的解决方案，所以使用它。但使用它只是为了吹嘘使用设计模式，就像拒绝使用它一样愚蠢，因为它只是一个全球性的。

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

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

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

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

单例使用静态方法实现。静态方法是做单元测试的人所避免的，因为它们不能被嘲笑或拒绝。这个网站上的大多数人都是单元测试的支持者。避免这种情况的最普遍接受的惯例是使用控制模式反转。

Singleton是一种模式，可以像任何其他工具一样被使用或滥用。

单例的坏部分通常是用户（或者我应该说单例不适合用于它不适合做的事情）。最大的违规行为是使用单例作为假全局变量。

假设该模式用于模型的某个方面，而该方面是真正的单一模式，则该模式没有本质上的错误。

我认为这种反弹是由于它的过度使用，而这反过来又是因为它是最容易理解和实施的模式。

单例模式本身不是问题。问题是，这种模式经常被使用面向对象工具开发软件的人所使用，而没有对OO概念的扎实掌握。当在这个上下文中引入单例时，它们往往会成长为不可管理的类，这些类包含了每个小用途的帮助器方法。

从测试的角度来看，单身也是一个问题。它们往往使孤立的单元测试难以编写。控制反转（IoC）和依赖注入是旨在以面向对象的方式解决这个问题的模式，这有助于单元测试。

在垃圾收集环境中，单体很快就会成为内存管理的问题。

还有多线程场景，单线程可能成为瓶颈和同步问题。