美化的全局变量-变成一个美化的全局类。有人说打破面向对象设计。
给我一些场景，除了使用单例是有意义的良好的老记录器。
当前回答
使用单例的方法之一是覆盖一个实例，其中必须有一个“代理”控制对资源的访问。单例在日志记录器中很好，因为它们代理访问，比如说，一个文件，这个文件只能被写入。对于像日志这样的东西，它们提供了一种方法来抽象出对日志文件之类的东西的写操作——你可以将缓存机制包装到你的单例中，等等……
也可以考虑这样一种情况，你有一个应用程序，有许多窗口/线程等，但它需要一个单一的通信点。我曾经使用它来控制我希望应用程序启动的作业。单例程序负责将作业序列化，并将它们的状态显示给程序中其他感兴趣的部分。在这种情况下，你可以把单例对象看作是在应用程序中运行的“服务器”类……HTH
其他回答
您可以在实现状态模式时使用单例(以GoF书中所示的方式)。这是因为具体的State类没有自己的状态，而是根据上下文类执行它们的操作。
你也可以让抽象工厂成为一个单例。
我认为如果你的应用程序有多个层次，如表示，领域和模型。Singleton是横切层的一个很好的候选者。并为系统各层提供服务。
从本质上讲，单例包装了一个服务，例如日志记录、分析，并将其提供给系统中的其他层。
是的，单例需要遵循单一责任原则。
单例候选人必须满足三个要求:
控制对共享资源的并发访问。 将从系统的多个不同部分请求对资源的访问。 只能有一个对象。
如果你提议的单例只有其中的一两个需求，那么重新设计几乎总是正确的选择。
例如，打印机假脱机程序不太可能从多个位置(打印菜单)调用，因此可以使用互斥来解决并发访问问题。
简单的日志记录器是可能有效的单例的最明显的例子，但这可能会在更复杂的日志记录方案中发生变化。
管理到数据库的连接(或连接池)。
我还会使用它来检索和存储外部配置文件中的信息。
当需要管理共享资源时，可以使用单例。例如打印机假脱机程序。您的应用程序应该只有一个假脱机程序实例，以避免对相同资源的请求冲突。
或者数据库连接或者文件管理器等等。
