我最近开始在我的一个项目中使用 DI。对于运行时依赖的类，我创建了相应的抽象工厂。遵循这种模式后，我最终拥有了太多的抽象工厂，几乎每个类(class)都有一个。
使用 IOC 时最终拥有太多抽象工厂是否很常见？
场景:假设我从数据库中获取“实体”对象。用户可以在此实体对象上执行 10 种不同的用例。对于每个用例，我都有一个不同的类来处理它。在某些情况下，给定的用例可能具有子用例组件，这些组件也可能需要实体对象。
由于这些类依赖于运行时实体对象，我必须为它们中的每一个创建抽象工厂。最后，我将构造指令连接到 IOC 容器中。
有没有其他方法可以做到这一点。我只是觉得创建所有这些工厂是浪费时间，特别是当所有子类都依赖于同一个实体对象时。
我倾向于使用 IOC 容器为我的场景注册一个工厂/构建器类。该工厂将为我的场景创建所需的对象图。我将 IOC 视为帮助实现 DI 概念的工具。只要我通过自定义构建器/工厂观察 DI，不一直使用 IOC 容器可能还不错。
我想知道你们如何看待这种方法？
最佳答案
听起来您正遭受 的折磨1:1 接口(interface)过多 .当这种情况发生时，通常表明人们应该停下来思考Reused Abstractions Principle。 .
也许你可以重新设计你的界面，以便有 less factories and more commands .
关于dependency-injection - 国际奥委会问题 : Too many Abstract Factories for Runtime data dependent classes，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6273583/