首先，一个类及其合作者应该首先实现其预期目的，而不是专注于依赖对象。生命周期管理（当实例被创建并且超出范围时）不应该是类责任的一部分。对此，公认的最佳实践是创建或配置一个新组件，以使用依赖注入来管理依赖关系。

通常，软件变得更加复杂，所以有多个状态不同的Singleton类的独立实例是有意义的。在这种情况下，提交代码来简单地抓取单例是错误的。使用Singleton.getInstance（）可能适用于小型简单系统，但当需要同一类的不同实例时，它无法工作/扩展。

任何类都不应该被认为是一个单独的类，而应该是它的用法或如何使用它来配置依赖项的应用程序。对于快速而令人讨厌的应用程序来说，这并不重要——只是简单的硬编码表示文件路径不重要，但对于更大的应用程序，需要使用DI以更合适的方式分解和管理这些依赖关系。

单例在测试中引起的问题是其硬编码的单一用例/环境的症状。测试套件和许多测试都是单独的，并且是独立的，与单例硬编码不兼容。

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

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

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

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

一些代码势利者看不起他们，认为他们只是一个荣耀的全球人。就像许多人讨厌goto语句一样，也有其他人讨厌使用全局的想法。我见过几位开发人员为了避免全局性而竭尽全力，因为他们认为使用全局性是失败的承认。奇怪但真实。

在实践中，Singleton模式只是一种编程技术，它是概念工具包的有用部分。有时你可能会发现它是理想的解决方案，所以使用它。但使用它只是为了吹嘘使用设计模式，就像拒绝使用它一样愚蠢，因为它只是一个全球性的。

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

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

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

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

当然，还要做到：

MessageQueue.Current.RegisterReceiver（this）；

在实现IMessageReceiver的类中。

太多人将非线程安全的对象放在单例模式中。尽管DataContext不是线程安全的，纯粹是一个工作单元对象，但我已经看到了DataContext（LINQ to SQL）以单例模式完成的示例。