美化的全局变量-变成一个美化的全局类。有人说打破面向对象设计。
给我一些场景,除了使用单例是有意义的良好的老记录器。
美化的全局变量-变成一个美化的全局类。有人说打破面向对象设计。
给我一些场景,除了使用单例是有意义的良好的老记录器。
当前回答
在我寻求真相的过程中,我发现实际上很少有“可接受的”理由使用Singleton。
在互联网上反复出现的一个原因是“日志记录”类(你提到过)。在这种情况下,可以使用Singleton来代替类的单个实例,因为日志类通常需要被项目中的每个类反复使用,令人作呕。如果每个类都使用这个日志类,依赖注入就变得很麻烦。
日志记录是“可接受的”单例的一个特定示例,因为它不会影响代码的执行。禁用日志记录,代码执行保持不变。启用它,一样。Misko在《单例的根本原因》中这样说:“这里的信息单向流动:从应用程序流向记录器。即使记录器是全局状态,由于没有信息从记录器流入应用程序,记录器也是可以接受的。”
我相信还有其他合理的原因。Alex Miller在“我讨厌的模式”中谈到,服务定位器和客户端UI也可能是“可接受的”选择。
阅读更多在Singleton我爱你,但你让我失望。
其他回答
只读单例存储一些全局状态(用户语言、帮助文件路径、应用程序路径)是合理的。使用单例控制业务逻辑时要小心——单例几乎总是以多例告终
正如大家所说,共享资源——特别是不能处理并发访问的资源。
我所见过的一个具体例子是Lucene搜索索引写入器。
将特定的基础设施关注点配置为单例或全局变量是非常实用的。我最喜欢的例子是依赖注入框架,它使用单例作为框架的连接点。
在这种情况下,您将依赖于基础设施来简化库的使用并避免不必要的复杂性。
当您想要确保一个类将有一个实例,并且该实例将有一个全局访问点时,您可以使用单例设计模式。
假设您有一个应用程序,它需要数据库来处理CRUD操作。理想情况下,您应该使用与数据库相同的连接对象来访问数据库并执行CRUD操作。
因此,为了确保数据库类有一个对象,并且该对象将在整个应用程序中使用,我们实现了单例设计模式。
确保构造函数是私有的,并且提供了一个静态方法来提供对单例类的单个对象的访问
我不认为Singleton的场景与记录器、打印机池或任何示例相关。
单例决策的目的是优化硬件资源,而不是只有一个地方来控制任何记录器或打印机池
我个人认为单例应该在以下情况下使用:
我们正在谈论的对象总是以相同的方式实例化(即任何共享资源,如Logger或打印机池) 它被多次调用(这可以是100或1000,这与您的资源有关) 你的硬件资源是有限的(例如内存、处理能力等)。
如果你有大量的内存空间和处理能力,我认为没有必要使用单例。
Singleton将确保你只有一个实例,并且是惰性加载的,那么如果它被调用一百万次,你就只创建了一个对象。