单例模式是GoF模式书中一个完全付费的成员，但最近它似乎被开发人员世界孤立了。我仍然使用了相当多的单线程，特别是对于工厂类，虽然你必须对多线程问题（像任何类一样）小心一点，但我不明白为什么它们如此糟糕。
Stack Overflow似乎特别假设每个人都认为Singleton是邪恶的。为什么？
请用“事实、参考资料或具体专业知识”来支持您的回答
当前回答
假设该模式用于模型的某个方面，而该方面是真正的单一模式，则该模式没有本质上的错误。
我认为这种反弹是由于它的过度使用，而这反过来又是因为它是最容易理解和实施的模式。
其他回答
我不打算评论善/恶的论点，但自从春天来临以来，我就没有使用过它们。使用依赖注入几乎消除了我对单例、服务定位器和工厂的需求。我发现这是一个更加高效和干净的环境，至少对于我所做的工作类型（基于Java的web应用程序）来说是如此。
它模糊了关注点的分离。
假设您有一个单例，您可以从类中的任何位置调用此实例。您的类不再像它应该的那样纯粹。您的类现在将不再对其成员及其显式接收的成员进行操作。这会造成混乱，因为类的用户不知道该类所需的足够信息是什么。封装的整个思想是向用户隐藏方法的方式，但如果在方法内部使用了单例，则必须知道单例的状态才能正确使用该方法。这是反OOP。
我想谈谈公认答案中的4点，希望有人能解释我为什么错了。
为什么在代码中隐藏依赖项不好？已经有几十个隐藏的依赖项（C运行时调用、OS API调用、全局函数调用），单例依赖项很容易找到（搜索instance（））。“使某个东西全局化以避免传递它是一种代码气味。”为什么不传递某个东西以避免使其成为单例代码气味？如果您通过调用堆栈中的10个函数传递一个对象，只是为了避免一个单例，那么这样做好吗？单一责任原则：我认为这有点模糊，取决于你对责任的定义。一个相关的问题是，为什么将这个特定的“责任”添加到一个班级中很重要？为什么将一个对象传递给一个类比将该对象作为类内的单例使用更紧密地耦合？为什么会改变国家的持续时间？单例对象可以手动创建或销毁，因此控件仍然存在，您可以使其生存期与非单例对象的生存期相同。
关于单元测试：
并非所有的类都需要是单位已测试并非所有需要成为单元的类测试需要更改单例的实现如果它们确实需要进行单元测试确实需要改变实施方式，很容易从使用singleton来实现通过依赖项传递给它的singleton注射
太多人将非线程安全的对象放在单例模式中。尽管DataContext不是线程安全的，纯粹是一个工作单元对象，但我已经看到了DataContext（LINQ to SQL）以单例模式完成的示例。
单身汉——反模式！马克·拉德福德（Mark Radford）的《过载杂志》（Overload Journal#57–2003年10月）很好地解释了为什么辛格尔顿被视为反模式。本文还讨论了替代Singleton的两种替代设计方法。
