哪个更邪恶：不必要的单身人士还是上帝对象？

Question

情况是这样的：我有一个班级做得太多了。 它主要用于访问配置信息，但它也有数据库连接。 它是作为单例实现的，因此这也使得单元测试变得困难，因为大多数代码与其紧密耦合。 这甚至会带来更大的问题，因为它会创建导入时依赖项（我们在 Python 中这样做），这意味着某些模块必须按特定顺序导入。 理想情况下，我想将其分为两个类并使其成为非单例。

幸运的是，我的雇主已经意识到这种测试是好的，并且愿意允许我进行这样的更改，如果它使代码更易于测试的话。 然而，我怀疑他们是否愿意让我花太多时间在这上面。 我宁愿逐步解决这个问题，也不愿过于激进。

因此，我在这里看到三个选择：

1. 将配置对象分解为（单例）配置对象和（非单例）数据库对象。 这至少允许我删除数据库作为导入时依赖项。
2. 使配置对象成为非单例并将其传递给需要它的对象。 我觉得这更好地满足了我们的短期需求，但我认为这将花费更多的时间。
3. 做一些我没有想到你在答案中建议的事情。 :-)

那我该怎么办？

Answer 1

我认为你们正朝着分成两个班级的方向发展。 您可能需要考虑使用工厂来根据需要创建数据库上下文/连接。 通过这种方式，您可以将连接视为根据需要创建/处置的工作实体单元，而不是在对象的生命周期中保留单个连接。 不过，YMMV。

至于配置，这是我发现单例可能是正确选择的一种情况。 我不一定会仅仅因为它很难进行单元测试而放弃它。 不过，您可能需要考虑构建它来实现接口。 然后，您可以在测试期间使用依赖项注入提供接口的模拟实例。 您的生产代码将被构建为在注入的值为 null 时使用单例实例，或者注入单例实例。 或者，您可以构造该类以允许通过私有方法重新初始化，并在安装/拆卸测试方法中调用它，以确保它具有适合您的测试的正确配置。 与后一种实现相比，我更喜欢前者，尽管当我无法直接控制界面时我也会使用它。

循序渐进地进行改变绝对是正确的方法。 如果可能的话，用测试包装当前功能，并确保这些测试在修改后仍然通过（当然，不是直接处理修改的测试）是确保不会破坏其他代码的好方法。

Answer 2

不看你的代码就很难知道，但为什么不按照你说的去做——增量地做呢？ 首先执行步骤1，拆分数据库。

如果速度很快，那么返回，现在您只有 1 个较小的对象（而不是 2 个）来停止成为单例。因此，第 2 步应该更快。 或者在这个阶段您可能会看到一些其他可以从单例中重构的代码。

希望您可以逐步减少单例中的内容，直到它消失，而无需在任何一步支付巨额时间税。

例如，如果配置的各部分是独立的，则也许可以一次将配置的一部分设为单例。 那么也许 GUI 配置在文件配置重构时保留了单例，或者类似的东西？

Answer 3

选项 1 是我在所有应用程序中所做的：配置对象单例和按需创建或注入的数据库对象。

将配置对象作为单例一直非常适合我。 只有一个配置文件，我总是想在应用程序启动时读取它。

Answer 4

请原谅我不懂任何Python，所以我希望任何伪代码都是有意义的......

我首先将对象分成两部分，这样你的单例的职责更小，然后我会采取剩余的配置单例并将其更改为普通类（就好像您要执行第二个建议一样）。

一旦我做到了这一点，我将创建一个新的包装器单例，它公开配置类的方法：

class ConfigurationWrapper : IConfigurationClass 
{
    public static property ConfigurationWrapper Instance;

    public property IConfigurationClass InnerClass;

    public method GetDefaultWindowWidth()
    {
        return InnerClass.GetDefaultWindowWidth();
    }

    etc...
}

现在应用程序要做的第一件事就是将 ConfigurationClass 的实例注入到包装器中。

ConfigurationClass config = new ConfigurationClass()
ConfigurationWrapper.Instance.InnerClass = config;

最后，您可以将当前依赖于单例的类移动到包装器单例（这应该是快速查找和替换）。 现在，您可以一次转换一个类，以通过其构造函数获取配置对象来完成第 2 阶段。您没有时间做的任何事情都可以使用包装器单例。 一旦你把它们全部搬过来，你就可以去掉包装纸了。

另一方面，您可以忽略用法的重构，只需将模拟的配置类注入到单例包装器中进行测试 - 本质上是穷人的依赖注入。