美化的全局变量-变成一个美化的全局类。有人说打破面向对象设计。
给我一些场景，除了使用单例是有意义的良好的老记录器。
当前回答
我不认为Singleton的场景与记录器、打印机池或任何示例相关。
单例决策的目的是优化硬件资源，而不是只有一个地方来控制任何记录器或打印机池
我个人认为单例应该在以下情况下使用:
我们正在谈论的对象总是以相同的方式实例化(即任何共享资源，如Logger或打印机池) 它被多次调用(这可以是100或1000，这与您的资源有关) 你的硬件资源是有限的(例如内存、处理能力等)。
如果你有大量的内存空间和处理能力，我认为没有必要使用单例。
Singleton将确保你只有一个实例，并且是惰性加载的，那么如果它被调用一百万次，你就只创建了一个对象。
其他回答
因此，我正在为学校阅读单例模式，教授们策划了一份关于该主题的当前观点和最佳实践的列表。似乎有一个共识，即如果构建时不向代码中添加任何内容，则可以使用单例。如果您使单例使用可以被开启和关闭，并且除了工作负载之外没有其他副作用，那么使用这种设计模式是安全的，也是可取的。
只读单例存储一些全局状态(用户语言、帮助文件路径、应用程序路径)是合理的。使用单例控制业务逻辑时要小心——单例几乎总是以多例告终
我不认为Singleton的场景与记录器、打印机池或任何示例相关。
单例决策的目的是优化硬件资源，而不是只有一个地方来控制任何记录器或打印机池
我个人认为单例应该在以下情况下使用:
我们正在谈论的对象总是以相同的方式实例化(即任何共享资源，如Logger或打印机池) 它被多次调用(这可以是100或1000，这与您的资源有关) 你的硬件资源是有限的(例如内存、处理能力等)。
如果你有大量的内存空间和处理能力，我认为没有必要使用单例。
Singleton将确保你只有一个实例，并且是惰性加载的，那么如果它被调用一百万次，你就只创建了一个对象。
管理到数据库的连接(或连接池)。
我还会使用它来检索和存储外部配置文件中的信息。
也许是一个带有代码的示例。
在这里，ConcreteRegistry是一个纸牌游戏中的单例，它允许行为沿着包树向上访问游戏的少数核心接口(即模型、视图、控制器、环境等的外观):
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs40.html
Ed.
