单例模式是GoF模式书中一个完全付费的成员，但最近它似乎被开发人员世界孤立了。我仍然使用了相当多的单线程，特别是对于工厂类，虽然你必须对多线程问题（像任何类一样）小心一点，但我不明白为什么它们如此糟糕。
Stack Overflow似乎特别假设每个人都认为Singleton是邪恶的。为什么？
请用“事实、参考资料或具体专业知识”来支持您的回答
当前回答
它模糊了关注点的分离。
假设您有一个单例，您可以从类中的任何位置调用此实例。您的类不再像它应该的那样纯粹。您的类现在将不再对其成员及其显式接收的成员进行操作。这会造成混乱，因为类的用户不知道该类所需的足够信息是什么。封装的整个思想是向用户隐藏方法的方式，但如果在方法内部使用了单例，则必须知道单例的状态才能正确使用该方法。这是反OOP。
其他回答
如果你使用得当且最少，单身汉并不是邪恶的。还有很多其他好的设计模式可以在某一点上替代单例的需求（也可以提供最佳结果）。但是一些程序员不知道这些好模式，在所有情况下都使用单例模式，这使得单例模式对他们来说是有害的。
首先，一个类及其合作者应该首先实现其预期目的，而不是专注于依赖对象。生命周期管理（当实例被创建并且超出范围时）不应该是类责任的一部分。对此，公认的最佳实践是创建或配置一个新组件，以使用依赖注入来管理依赖关系。
通常，软件变得更加复杂，所以有多个状态不同的Singleton类的独立实例是有意义的。在这种情况下，提交代码来简单地抓取单例是错误的。使用Singleton.getInstance（）可能适用于小型简单系统，但当需要同一类的不同实例时，它无法工作/扩展。
任何类都不应该被认为是一个单独的类，而应该是它的用法或如何使用它来配置依赖项的应用程序。对于快速而令人讨厌的应用程序来说，这并不重要——只是简单的硬编码表示文件路径不重要，但对于更大的应用程序，需要使用DI以更合适的方式分解和管理这些依赖关系。
单例在测试中引起的问题是其硬编码的单一用例/环境的症状。测试套件和许多测试都是单独的，并且是独立的，与单例硬编码不兼容。
它很容易（ab）用作全局变量。依赖于单态的类相对来说更难单独进行单元测试。
单例使用静态方法实现。静态方法是做单元测试的人所避免的，因为它们不能被嘲笑或拒绝。这个网站上的大多数人都是单元测试的支持者。避免这种情况的最普遍接受的惯例是使用控制模式反转。
当您使用单例（例如，记录器或数据库连接）编写代码时，然后发现您需要多个日志或多个数据库，您就遇到了麻烦。
单身者很难从他们身上转移到普通物体上。
此外，编写非线程安全的单例也太容易了。
您应该将所有需要的实用程序对象从一个函数传递到另一个函数，而不是使用单例。如果您将所有这些对象包装到一个辅助对象中，这可以简化，如下所示：
void some_class::some_function(parameters, service_provider& srv)
{
srv.get<error_logger>().log("Hi there!");
this->another_function(some_other_parameters, srv);
}
