What’s wrong with singleton?
Singletons: good design or a crutch?
Singleton: How should it be used
What is so bad about Singletons
您可以找到许多使用单例而不是静态类的原因。但是在某些情况下，在 Singleton 之前使用静态类肯定会更好。它们是什么？
【问题讨论】：
您可以在以下情况下使用静态类：
1) 它的所有方法都是实用程序（很好的例子 - 数学类）
2) 你不想处理从垃圾收集器中保存你的实例（在小程序中），但我最好在那里使用单例
3) 你绝对确信它在未来不会变成有状态的并且你确信你总是只需要那个类的一个实例
如果你正在使用单例，并且在某一刻你意识到你需要多个实例，那么你的单例可以很容易地转换为多调，但是你会遇到静态类的问题
【讨论】：
多年来，我一直在与静态类消费者的可测试性作斗争，老实说，它们是邪恶思想的产物。不过说真的，我会在 C# 中将静态类用于扩展方法，但在其他任何地方都不会。
【讨论】：
如果您的类不存储任何状态，则使用静态类。
如果它存储状态并且您需要单个实例，那么（也许）使用 Singleton。
否则使用常规类。
【讨论】：
当您不需要更改实现时，静态类会更好。使用 Singleton，您可以拥有具有各种实现的接口。一个静态类，只能是一个实现。
【讨论】：
单例是只能实例化一个实例的类，而没有与静态方法关联的实例。
如果您可以使用单个静态方法实现您想要的功能，那么这可能是您最好的方法，因为它更容易实现。考虑扩展方法——它们只是带有语法糖的静态方法。如果您可以在逻辑上将静态方法视为现有类的帮助器，那么使用静态方法是有意义的。
另一方面，如果您尝试实现的功能涉及某种状态，那么最好使用 Singleton 代替。 Singleton 对象可以包含/管理其状态并管理并发访问/线程，而使用静态类和静态方法会变得更加复杂。如果您在 C# 中使用单例，我强烈建议您阅读 Jon Skeet 关于正确单例实现的文章，该文章可在 http://www.yoda.arachsys.com/csharp/singleton.html 获得。
与静态方法相比，单例与静态类的可比性更高。在此比较中，单例的一大优势是它们可以实现接口并从基类派生。这允许您将它们的实现与它们的接口分离。例如，如果我的核心程序集中有一个接口 IAccountService 和一个单例实现，SingletonAspNetAccountService 在我的服务层中，那么我可以将IAccountService 注入到我的 UI 层中，使用 IoC 容器，而不需要依赖我的服务层在 UI 层。另一方面，如果我有一个静态的Accounts 类，那么我必须为静态类的方法创建一个适配器，或者在我的 UI 中依赖服务层才能访问静态帐户功能。
【讨论】：
它始终是您实际上不需要在任何地方传递单例实例的地方。 例如，如果单例实现了某个接口，它将很有用，而您不能使用静态类来实现。
请记住，每个 Class 实例都是一个单例，由 JVM 管理。 所以静态类是单例的。
【讨论】：