design-patterns - 在实践中如何避免/重构糟糕的单例？

Question

在仔细阅读有关单例的事实(代码味道，而不是模式)之后，我想知道:

如何重构我的代码以摆脱它们？

尽管几乎每个人都同意糟糕的单例是，嗯，很糟糕，但我找不到任何关于如何替换它们的实用建议。要么非常琐碎，要么非常困难。

我能想到一些方法，但所有这些方法似乎都让我的代码变得非常臃肿。

例如，假设我有一个“全局”AppConfig持有有关产品的许可证信息并描述用户可用的功能的类。

我能想到的:

为我的项目的每个类创建一个公共(public)基类，其中包含 AppConfig实例。 (不好:对于已经有基类的情况，例如表单，这是不可能的)

使用 setAppConfig 创建一个通用接口(interface)方法。

创建全局AppConfigFactory可以创建AppConfig实例(坏:仅将问题转移到另一个类)

将实例作为参数传递给需要它的每个方法。 (坏:代码膨胀)

...

我能做些什么？

编辑:澄清:我在我的代码中发现了一个错误的单例。现在我想重构我的代码以删除它。我正在寻求有关如何实现这一目标的提示和一般想法。

Answer 1

使用依赖注入(inject)和控制反转框架——这可能需要大量的重构。然后，使用构造函数或属性依赖，请求“单例” - 理想情况下，你不要求整个事情，因为根据 Demeter 的原则，它应该只要求它真正需要的东西(在你的情况下是许可证信息)。

我试图区分单例(反模式伪装全局变量)和单例(意味着你只需要其中一个)。真正的单例在程序开始时(或在您的工厂中)创建一次，并传递给需要它的对象。