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

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


当前回答

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

其他回答

将特定的基础设施关注点配置为单例或全局变量是非常实用的。我最喜欢的例子是依赖注入框架,它使用单例作为框架的连接点。

在这种情况下,您将依赖于基础设施来简化库的使用并避免不必要的复杂性。

共享资源。特别是在PHP中,数据库类、模板类和全局变量库类。所有这些都必须由代码中使用的所有模块/类共享。

这是一个真正的对象使用——>模板类包含正在构建的页面模板,它被添加到页面输出的模块塑造、添加、更改。它必须保持为单个实例,这样才能实现这一点,数据库也是如此。使用共享数据库单例,所有模块的类都可以访问查询,并且无需重新运行查询。

全局变量仓库单例为您提供了一个全局的、可靠的、易于使用的变量仓库。它极大地整理了你的代码。想象一下,所有配置值都在一个单例数组中,如下所示:

美元gb - > problem[’hostname’]

或者将所有的语言值放在一个数组中,比如:

gb - >朗(“ENTER_USER”)

在运行页面代码的最后,你会得到,比如说,一个现在成熟的:

美元的模板

Singleton,一个$gb的Singleton,其中有lang数组用于替换,所有输出都已加载并准备就绪。您只需将它们替换为现在在成熟模板对象的页面值中呈现的键,然后将其提供给用户。

这样做的最大好处是你可以对任何东西做任何你喜欢的后期处理。您可以将所有语言值输送到谷歌translate或其他翻译服务,并将它们返回,并将它们替换到它们的位置,例如,已翻译。或者,您可以根据需要替换页面结构或内容字符串。

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

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

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

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

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

只读单例存储一些全局状态(用户语言、帮助文件路径、应用程序路径)是合理的。使用单例控制业务逻辑时要小心——单例几乎总是以多例告终

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

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