design-patterns - 哪个更邪恶: an unnecessary singleton or a God Object?

Question

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

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

所以，我在这里看到三个选择:

将配置对象分解为(单例)配置对象和(非单例)数据库对象。这至少可以让我将数据库作为导入时依赖项删除。

使配置对象成为非单例并将其传递给需要它的对象。我觉得这更好地满足了我们的短期需求，但我认为这需要更多的时间。

做一些我没有想到的你在回答中建议的事情。 :-)

那我该怎么办？

Answer 1

我认为您有望分成两个类(class)。您可能需要考虑使用工厂来根据需要创建数据库上下文/连接。这样，您可以将连接视为根据需要创建/处置的工作实体单元，而不是在对象的生命周期内保持单个连接。不过，YMMV。

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

逐步进行更改绝对是要走的路。如果可能的话，用测试包装当前的功能，并确保这些测试在你的修改之后仍然通过(当然，不是那些直接处理你的修改的测试)是确保你没有破坏其他代码的好方法.