编写可测试代码导致工厂过多答案

【问题标题】：Too many factories as a result of writing testable code编写可测试代码导致工厂过多
【发布时间】：2010-12-27 10:29:14
【问题描述】：

我正在尝试编写易于测试的代码。这导致我避免直接调用 new Class1() 。相反，我通常创建一个接口，一个简单的工厂，带有一个返回此接口的 GetObject() 方法。

它工作正常。我发现的问题是太多的工厂除了调用 new Class1() （或他们负责创建的任何类/接口）之外基本上什么都没有。我不认为为拥有可测试的代码付出很大的代价，但仍然......有没有人使用更好的方法并且仍然实现能够在测试时注入 Class1 的不同实现的目标？

我知道我可以将 Class1 实现公开为属性并在运行时使用默认值，但这意味着我仅限于一个实例，而在许多情况下，我想在每次需要 Class1 时创建一个新实例。

编辑：
我确实使用 IoC，这确实有帮助。尽管如此，我通常最终会在 IoC 配置中将工厂作为依赖项。我的 GetObject 方法通常调用类似 IoC.Resolve 的方法。我更喜欢在工厂中隔离 IoC 依赖，而不是直接在包含业务逻辑的域类中。

【问题讨论】：

【解决方案1】：

有许多框架可以帮助实现这一目标。该技术称为控制反转。 .NET 世界中的示例：

所有这些框架的共同点是能够将组件（类）之间的绑定外部化为配置，该配置可以表示为配置文件（即 XML）或“引导”代码。它们能够自动将依赖项注入实例并为您解决类实例化和配置的问题。基本上，您可以将此任务留在 IoC 容器上并退出创建自定义工厂类。

关于 SO 的相关资源标记为ioc-container。

Martin Fowler 有一个 article，描述了 IoC 和依赖注入和服务定位器等实现技术。

【讨论】：

【解决方案2】：

如果我知道你在说什么语言会更容易，但大多数语言都有一些泛型或其他的概念。因此，您可以使您的工厂接口成为通用接口：

Java 版本：

public interface Factory<K>{
    K create();
}

Guava Libraries 具有Supplier<K> 接口正是为此目的。我建议使用这样的准标准（我想其他语言也可以使用类似的东西）。

【讨论】：