美化的全局变量-变成一个美化的全局类。有人说打破面向对象设计。
给我一些场景，除了使用单例是有意义的良好的老记录器。
当前回答
当您想要确保一个类将有一个实例，并且该实例将有一个全局访问点时，您可以使用单例设计模式。
假设您有一个应用程序，它需要数据库来处理CRUD操作。理想情况下，您应该使用与数据库相同的连接对象来访问数据库并执行CRUD操作。
因此，为了确保数据库类有一个对象，并且该对象将在整个应用程序中使用，我们实现了单例设计模式。
确保构造函数是私有的，并且提供了一个静态方法来提供对单例类的单个对象的访问
其他回答
使用单例的方法之一是覆盖一个实例，其中必须有一个“代理”控制对资源的访问。单例在日志记录器中很好，因为它们代理访问，比如说，一个文件，这个文件只能被写入。对于像日志这样的东西，它们提供了一种方法来抽象出对日志文件之类的东西的写操作——你可以将缓存机制包装到你的单例中，等等……
也可以考虑这样一种情况，你有一个应用程序，有许多窗口/线程等，但它需要一个单一的通信点。我曾经使用它来控制我希望应用程序启动的作业。单例程序负责将作业序列化，并将它们的状态显示给程序中其他感兴趣的部分。在这种情况下，你可以把单例对象看作是在应用程序中运行的“服务器”类……HTH
将特定的基础设施关注点配置为单例或全局变量是非常实用的。我最喜欢的例子是依赖注入框架，它使用单例作为框架的连接点。
在这种情况下，您将依赖于基础设施来简化库的使用并避免不必要的复杂性。
我认为如果你的应用程序有多个层次，如表示，领域和模型。Singleton是横切层的一个很好的候选者。并为系统各层提供服务。
从本质上讲，单例包装了一个服务，例如日志记录、分析，并将其提供给系统中的其他层。
是的，单例需要遵循单一责任原则。
当你加载一个配置属性对象时，无论是从数据库还是从文件中，将它作为一个单例都会有所帮助;没有理由在服务器运行时重新读取不会改变的静态数据。
只读单例存储一些全局状态(用户语言、帮助文件路径、应用程序路径)是合理的。使用单例控制业务逻辑时要小心——单例几乎总是以多例告终
