这并不是说单体本身是坏的，而是GoF设计模式是坏的。唯一真正有效的论点是，GoF设计模型不适合测试，尤其是在并行运行测试的情况下。

只要在代码中应用以下方法，使用类的单个实例就是有效的构造：

确保将用作单例的类实现了一个接口。这允许使用相同的接口实现存根或模拟确保Singleton是线程安全的。这是给的。单例应该是简单的，而不是过于复杂。在应用程序的运行时，如果需要将单例传递给给定对象，请使用构建该对象的类工厂，并让类工厂将单例实例传递给需要它的类。在测试期间，为了确保确定性行为，将单例类创建为单独的实例，作为实际类本身或实现其行为的存根/模拟，并将其原样传递给需要它的类。不要使用在测试期间创建需要单例的被测对象的类因子，因为它将传递其单个全局实例，这违背了目的。

我们已经在我们的解决方案中使用了Singleton，并取得了巨大的成功，这些成功是可测试的，确保了并行测试运行流中的确定性行为。

单身汉——反模式！马克·拉德福德（Mark Radford）的《过载杂志》（Overload Journal#57–2003年10月）很好地解释了为什么辛格尔顿被视为反模式。本文还讨论了替代Singleton的两种替代设计方法。

单身汉还不错。只有当你做了一些全球独一无二的东西而不是全球独一无二的时候，才是糟糕的。

然而，有“应用程序范围服务”（想想让组件交互的消息传递系统）-这是一个单例调用，一个“MessageQueue”-类，它有一个方法“SendMessage（…）”。

然后，您可以在各地执行以下操作：

MessageQueue.Current.SendMessage（新邮件到达消息（…））；

当然，还要做到：

MessageQueue.Current.RegisterReceiver（this）；

在实现IMessageReceiver的类中。

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

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

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

单线态的问题是范围增加，因此耦合的问题。不可否认，在某些情况下，您确实需要访问单个实例，并且可以通过其他方式实现。

我现在更喜欢围绕控制反转（IoC）容器进行设计，并允许容器控制生命周期。这为依赖于实例的类提供了好处，使它们不知道存在单个实例的事实。将来可以更改单例的生存期。我最近遇到的一个例子是从单线程到多线程的简单调整。

FWIW，如果你尝试单元测试它时它是一个PIA，那么当你尝试调试、修复或增强它时，它就会变成PIA。

作者的一些对位词：

如果你将来需要让班级不再单身，你就会陷入困境一点也不——我当时使用的是一个数据库连接单例，我想将其转换为一个连接池。请记住，每个单例都是通过标准方法访问的：

我的类别实例

这类似于工厂方法的签名。我所做的只是更新实例方法以返回池中的下一个连接，无需进行其他更改。如果我们没有使用单例的话，那就更难了。

单身汉只是花式的全球明星这一点无可厚非，但所有静态字段和方法也是如此——从类而不是实例访问的任何东西本质上都是全局的，我看不出静态字段的使用有多大阻碍？

并不是说单身汉很好，只是反驳了这里的一些“传统智慧”。