美化的全局变量-变成一个美化的全局类。有人说打破面向对象设计。
给我一些场景，除了使用单例是有意义的良好的老记录器。
当前回答
将特定的基础设施关注点配置为单例或全局变量是非常实用的。我最喜欢的例子是依赖注入框架，它使用单例作为框架的连接点。
在这种情况下，您将依赖于基础设施来简化库的使用并避免不必要的复杂性。
其他回答
管理到数据库的连接(或连接池)。
我还会使用它来检索和存储外部配置文件中的信息。
当需要管理共享资源时，可以使用单例。例如打印机假脱机程序。您的应用程序应该只有一个假脱机程序实例，以避免对相同资源的请求冲突。
或者数据库连接或者文件管理器等等。
当管理对整个应用程序共享的资源的访问时，应该使用单例，并且可能存在同一个类的多个实例将是破坏性的。确保对共享资源的访问线程安全是这种模式至关重要的一个很好的例子。
当使用单例时，你应该确保你不会意外地隐藏依赖关系。理想情况下，单例对象(就像应用程序中的大多数静态变量一样)在应用程序的初始化代码执行期间设置(c#可执行文件为静态void Main()， java可执行文件为静态void Main())，然后传递给所有其他需要它的实例化类。这有助于维护可测试性。
因此，我正在为学校阅读单例模式，教授们策划了一份关于该主题的当前观点和最佳实践的列表。似乎有一个共识，即如果构建时不向代码中添加任何内容，则可以使用单例。如果您使单例使用可以被开启和关闭，并且除了工作负载之外没有其他副作用，那么使用这种设计模式是安全的，也是可取的。
单例候选人必须满足三个要求:
控制对共享资源的并发访问。 将从系统的多个不同部分请求对资源的访问。 只能有一个对象。
如果你提议的单例只有其中的一两个需求，那么重新设计几乎总是正确的选择。
例如，打印机假脱机程序不太可能从多个位置(打印菜单)调用，因此可以使用互斥来解决并发访问问题。
简单的日志记录器是可能有效的单例的最明显的例子，但这可能会在更复杂的日志记录方案中发生变化。
