美化的全局变量-变成一个美化的全局类。有人说打破面向对象设计。

给我一些场景,除了使用单例是有意义的良好的老记录器。


当前回答

读取应该只在启动时读取的配置文件,并将它们封装在Singleton中。

其他回答

当需要管理共享资源时,可以使用单例。例如打印机假脱机程序。您的应用程序应该只有一个假脱机程序实例,以避免对相同资源的请求冲突。

或者数据库连接或者文件管理器等等。

单例候选人必须满足三个要求:

控制对共享资源的并发访问。 将从系统的多个不同部分请求对资源的访问。 只能有一个对象。

如果你提议的单例只有其中的一两个需求,那么重新设计几乎总是正确的选择。

例如,打印机假脱机程序不太可能从多个位置(打印菜单)调用,因此可以使用互斥来解决并发访问问题。

简单的日志记录器是可能有效的单例的最明显的例子,但这可能会在更复杂的日志记录方案中发生变化。

使用单例的方法之一是覆盖一个实例,其中必须有一个“代理”控制对资源的访问。单例在日志记录器中很好,因为它们代理访问,比如说,一个文件,这个文件只能被写入。对于像日志这样的东西,它们提供了一种方法来抽象出对日志文件之类的东西的写操作——你可以将缓存机制包装到你的单例中,等等……

也可以考虑这样一种情况,你有一个应用程序,有许多窗口/线程等,但它需要一个单一的通信点。我曾经使用它来控制我希望应用程序启动的作业。单例程序负责将作业序列化,并将它们的状态显示给程序中其他感兴趣的部分。在这种情况下,你可以把单例对象看作是在应用程序中运行的“服务器”类……HTH

我认为单例的使用与数据库中的多对一关系是一样的。如果代码中有许多不同的部分需要处理对象的单个实例,那么使用单例就很有意义了。

因此,我正在为学校阅读单例模式,教授们策划了一份关于该主题的当前观点和最佳实践的列表。似乎有一个共识,即如果构建时不向代码中添加任何内容,则可以使用单例。如果您使单例使用可以被开启和关闭,并且除了工作负载之外没有其他副作用,那么使用这种设计模式是安全的,也是可取的。