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

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

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

I use it for an object encapsulating command-line parameters when dealing with pluggable modules. The main program doesn't know what the command-line parameters are for modules that get loaded (and doesn't always even know what modules are being loaded). e.g., main loads A, which doesn't need any parameters itself (so why it should take an extra pointer / reference / whatever, I'm not sure - looks like pollution), then loads modules X, Y, and Z. Two of these, say X and Z, need (or accept) parameters, so they call back to the command-line singleton to tell it what parameters to accept, and the at runtime they call back to find out if the user actually has specified any of them.

在很多方面，处理CGI参数的单例方式与你每次查询只使用一个进程类似(其他mod_*方法不这样做，所以这很糟糕——因此这个参数说你不应该在mod_cgi世界中使用单例，以防你移植到mod_perl或其他世界)。

也许是一个带有代码的示例。

在这里，ConcreteRegistry是一个纸牌游戏中的单例，它允许行为沿着包树向上访问游戏的少数核心接口(即模型、视图、控制器、环境等的外观):

http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs40.html

Ed.

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

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

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

美元gb - > problem[’hostname’]

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

gb - >朗(“ENTER_USER”)

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

美元的模板

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

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

当管理对整个应用程序共享的资源的访问时，应该使用单例，并且可能存在同一个类的多个实例将是破坏性的。确保对共享资源的访问线程安全是这种模式至关重要的一个很好的例子。

当使用单例时，你应该确保你不会意外地隐藏依赖关系。理想情况下，单例对象(就像应用程序中的大多数静态变量一样)在应用程序的初始化代码执行期间设置(c#可执行文件为静态void Main()， java可执行文件为静态void Main())，然后传递给所有其他需要它的实例化类。这有助于维护可测试性。