还有一件关于单身汉的事，还没有人说过。

在大多数情况下，“singletony”是某个类的实现细节，而不是其接口的特征。控制容器的反转可能会对类用户隐藏此特性；您只需要将类标记为singleton（例如，在Java中使用@singleton注释），就可以了；IoCC将完成剩下的工作。您不需要提供对单例实例的全局访问，因为访问已经由IoCC管理。因此，IoC Singleton没有任何问题。

与IoC Singleton相反的GoF Singleton应该通过getInstance（）方法在接口中暴露“singletony”，因此他们会受到上面所说的一切影响。

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

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

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

单身者在集群方面也很糟糕。因为这样，您的应用程序中就不再有“恰好一个单例”了。

考虑以下情况：作为开发人员，您必须创建一个访问数据库的web应用程序。为了确保并发数据库调用不会相互冲突，您可以创建一个线程保存SingletonDao：

public class SingletonDao {
    // songleton's static variable and getInstance() method etc. omitted
    public void writeXYZ(...){
        synchronized(...){
            // some database writing operations...
        }
    }
}

因此，您可以确定应用程序中只存在一个singleton，并且所有数据库都通过这一个也是唯一的SingletonDao。您的生产环境现在如下所示：

到目前为止一切都很好。

现在，考虑您想在集群中设置web应用程序的多个实例。现在，你突然有了这样的想法：

这听起来很奇怪，但现在您的应用程序中有很多单例。这正是单例不应该是的：它有很多对象。如果您想对数据库进行同步调用，如本例所示，这尤其糟糕。

当然，这是单例用法错误的一个例子。但是这个例子的信息是：你不能相信你的应用程序中只有一个单例实例，特别是在集群方面。

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

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

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

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

当您使用单例（例如，记录器或数据库连接）编写代码时，然后发现您需要多个日志或多个数据库，您就遇到了麻烦。

单身者很难从他们身上转移到普通物体上。

此外，编写非线程安全的单例也太容易了。

您应该将所有需要的实用程序对象从一个函数传递到另一个函数，而不是使用单例。如果您将所有这些对象包装到一个辅助对象中，这可以简化，如下所示：

void some_class::some_function(parameters, service_provider& srv)
{
    srv.get<error_logger>().log("Hi there!");
    this->another_function(some_other_parameters, srv);
}