我正在尝试编写可以轻松测试的代码。这导致我避免直接调用新的Class1（）。相反，我通常创建一个接口，一个简单的工厂，其中一个GetObject（）方法返回此接口。
工作正常。我发现的问题是太多的工厂除了调用新的Class1（）（或者他们负责创建的任何类/接口）之外什么都没有。我不认为支付可测试代码是一个很大的代价，但仍然......有没有人使用更好的方法，仍然能够在测试时注入不同的Class1实现目标？
我知道我可以将Class1实现公开为属性并在运行时使用默认值但这意味着我只限于一个实例，而在许多情况下我想在每次需要Class1时创建一个新实例。 / p>
编辑：
我确实使用IoC，这确实有帮助。尽管如此，我通常最终将工厂作为IoC配置中的依赖项。我的GetObject方法通常调用IoC.Resolve之类的东西。我更喜欢在工厂中隔离IoC依赖项，而不是直接在包含业务逻辑的域类中。
答案 0 :(得分：3)
有许多框架可以帮助实现这一目标。该技术称为控制反转。 .NET世界中的示例：
所有这些框架的共同点是能够将组件（类）之间的绑定外部化为配置，该配置表示为配置文件（即XML）或“引导”代码。它们能够自动将依赖项注入实例，并为您解决类实例化和配置问题。基本上，您可以将此任务留在IoC容器上并退出创建自定义工厂类。
SO上的相关资源标记为ioc-container。
Martin Fowler有article描述IoC和依赖注入和服务定位器等实现技术。
答案 1 :(得分：2)
如果我知道你在说什么语言会更容易，但大多数语言都有一些泛型或其他的概念。因此，您可以使您的工厂界面成为通用界面：
Java版：
public interface Factory<K>{
K create();
}
Guava Libraries具有Supplier<K>接口，正是出于此目的。我建议使用这样的准标准（我猜其他语言也可以使用类似的东西）。