单例模式是GoF模式书中一个完全付费的成员，但最近它似乎被开发人员世界孤立了。我仍然使用了相当多的单线程，特别是对于工厂类，虽然你必须对多线程问题（像任何类一样）小心一点，但我不明白为什么它们如此糟糕。
Stack Overflow似乎特别假设每个人都认为Singleton是邪恶的。为什么？
请用“事实、参考资料或具体专业知识”来支持您的回答
当前回答
首先，一个类及其合作者应该首先实现其预期目的，而不是专注于依赖对象。生命周期管理（当实例被创建并且超出范围时）不应该是类责任的一部分。对此，公认的最佳实践是创建或配置一个新组件，以使用依赖注入来管理依赖关系。
通常，软件变得更加复杂，所以有多个状态不同的Singleton类的独立实例是有意义的。在这种情况下，提交代码来简单地抓取单例是错误的。使用Singleton.getInstance（）可能适用于小型简单系统，但当需要同一类的不同实例时，它无法工作/扩展。
任何类都不应该被认为是一个单独的类，而应该是它的用法或如何使用它来配置依赖项的应用程序。对于快速而令人讨厌的应用程序来说，这并不重要——只是简单的硬编码表示文件路径不重要，但对于更大的应用程序，需要使用DI以更合适的方式分解和管理这些依赖关系。
单例在测试中引起的问题是其硬编码的单一用例/环境的症状。测试套件和许多测试都是单独的，并且是独立的，与单例硬编码不兼容。
其他回答
我不打算评论善/恶的论点，但自从春天来临以来，我就没有使用过它们。使用依赖注入几乎消除了我对单例、服务定位器和工厂的需求。我发现这是一个更加高效和干净的环境，至少对于我所做的工作类型（基于Java的web应用程序）来说是如此。
单身汉——反模式！马克·拉德福德（Mark Radford）的《过载杂志》（Overload Journal#57–2003年10月）很好地解释了为什么辛格尔顿被视为反模式。本文还讨论了替代Singleton的两种替代设计方法。
单例使用静态方法实现。静态方法是做单元测试的人所避免的，因为它们不能被嘲笑或拒绝。这个网站上的大多数人都是单元测试的支持者。避免这种情况的最普遍接受的惯例是使用控制模式反转。
当几个人（或团队）达成类似或相同的解决方案时，就会出现一种模式。许多人仍然使用原始形式的单件或使用工厂模板（Alexandrescu的《现代C++设计》中有很好的讨论）。并发性和管理对象生存期的困难是主要障碍，前者很容易按照您的建议进行管理。
和所有的选择一样，辛格尔顿也有其沉浮的部分。我认为它们可以适度使用，特别是对于在应用程序寿命期内仍然存在的对象。事实上，它们类似于（而且很可能是）全球性的，这可能引发了纯粹主义者。
如果你使用得当且最少，单身汉并不是邪恶的。还有很多其他好的设计模式可以在某一点上替代单例的需求（也可以提供最佳结果）。但是一些程序员不知道这些好模式，在所有情况下都使用单例模式，这使得单例模式对他们来说是有害的。
