在我寻求真相的过程中，我发现实际上很少有“可接受的”理由使用Singleton。

在互联网上反复出现的一个原因是“日志记录”类(你提到过)。在这种情况下，可以使用Singleton来代替类的单个实例，因为日志类通常需要被项目中的每个类反复使用，令人作呕。如果每个类都使用这个日志类，依赖注入就变得很麻烦。

日志记录是“可接受的”单例的一个特定示例，因为它不会影响代码的执行。禁用日志记录，代码执行保持不变。启用它，一样。Misko在《单例的根本原因》中这样说:“这里的信息单向流动:从应用程序流向记录器。即使记录器是全局状态，由于没有信息从记录器流入应用程序，记录器也是可以接受的。”

我相信还有其他合理的原因。Alex Miller在“我讨厌的模式”中谈到，服务定位器和客户端UI也可能是“可接受的”选择。

阅读更多在Singleton我爱你，但你让我失望。

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

一个实例可以在Test::Builder中找到，这个类支持几乎所有现代Perl测试模块。Builder单例存储并代理测试流程的状态和历史记录(历史测试结果，计算运行的测试次数)以及测试输出流向等内容。这些都是协调由不同作者编写的多个测试模块以在单个测试脚本中一起工作所必需的。

The history of Test::Builder's singleton is educational. Calling new() always gives you the same object. First, all the data was stored as class variables with nothing in the object itself. This worked until I wanted to test Test::Builder with itself. Then I needed two Test::Builder objects, one setup as a dummy, to capture and test its behavior and output, and one to be the real test object. At that point Test::Builder was refactored into a real object. The singleton object was stored as class data, and new() would always return it. create() was added to make a fresh object and enable testing.

Currently, users are wanting to change some behaviors of Test::Builder in their own module, but leave others alone, while the test history remains in common across all testing modules. What's happening now is the monolithic Test::Builder object is being broken down into smaller pieces (history, output, format...) with a Test::Builder instance collecting them together. Now Test::Builder no longer has to be a singleton. Its components, like history, can be. This pushes the inflexible necessity of a singleton down a level. It gives more flexibility to the user to mix-and-match pieces. The smaller singleton objects can now just store data, with their containing objects deciding how to use it. It even allows a non-Test::Builder class to play along by using the Test::Builder history and output singletons.

似乎在数据的协调和行为的灵活性之间存在着一种推拉关系，这种关系可以通过在共享数据周围使用尽可能少的行为来缓解，以确保数据的完整性。

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或其他世界)。

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

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

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

美元gb - > problem[’hostname’]

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

gb - >朗(“ENTER_USER”)

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

美元的模板

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

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

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

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