【问题标题】：Alternative to Singleton Pattern for an application settings manager应用程序设置管理器的单例模式的替代方案
【发布时间】：2012-06-17 19:44:22
【问题描述】：

我已经阅读了单例导致代码出现问题的所有原因，但在以下场景中我找不到替代方案。

我有一个 Java Swing 应用程序。用户可以通过 GUI 设置影响应用程序的显示和功能的设置，这些设置从 XML 配置文件中存储和检索。加载应用程序时，会构造一个 SettingsManager 对象。在构造函数中，设置管理器解析 XML 配置文件并将所有设置存储在本地以便快速访问（我将其称为缓存）。当应用程序中的设置发生更改时，该设置会立即写入文件，但缓存会同时更新。

问题

如果设置管理器的多个实例被创建，当其中一个设置被更改时，其他的缓存变得陈旧。如果不使用单例，解决此问题的一种可能方法是不使用缓存并始终从文件中检索设置。这不是一个可怕的想法，但它并不可取。如果我这样做了，我想我必须做一些额外的工作才能使其线程安全。

为什么单例有帮助

如果 SettingsManager 是 Singleton，则只有一个缓存，因此它永远不会过时。但是，我已经看到这不是一个好主意，因为它现在本质上是一个全局变量，不需要访问设置的类现在可以访问它们。从我一直在阅读的内容来看，还有很多其他问题。

那么有没有其他的设计方法可以在不使用 Singleton 的情况下解决问题？

【问题讨论】：

需要访问设置的类应该已经被注入了。
您可以使用静态全局变量...或使用某种管理器类并传递对象的实例。您还可以实现某种引用计数方案并将此类限制为一个实例。
您可以使用依赖注入库来访问您的类的单个实例，而无需实现 Singleton。
单例是为了解决静态全局变量的问题而创建的。
在这里您可以阅读有关单例和依赖注入的信息：androidsx.com/cant-test-that-singleton-try-dependency-injection 和：stackoverflow.com/questions/246963/…

标签： design-patterns singleton settings application-settings

【解决方案1】：

您可以实现它，以便在类内部将 SettingsManager 作为 Singleton 进行管理（该类显然不会是单例），并且该类实例只会被注入那些需要它的类中。手柄体（AKA 桥）可以很好地工作。

这会让你两全其美：

SettingsManager 只实例化一次，它的缓存也是如此。而且缓存永远不会过时。
只有需要它的对象才能访问它

显然，这个句柄主体类（或任何其他解决方案）可以在任何地方实例化，从而绕过依赖注入。所以我不确定这个问题是否存在完美的解决方案，但这可以让你更进一步。

【讨论】：

【解决方案2】：

让我跟进 Brady 的回答，并建议将“handle-body”类上的方法声明为 protected。这将限制其可用性。另一种技术是将类放在包含名称“内部”的包中（例如 com.mycorp.abc.internal）。这可能不会限制访问，但它确实向其他开发人员发出了一个明确的信息，即确实不应该使用该类/方法。

【讨论】：