为何使用Abstract Factory模式？Clean Architecture相关疑问

你提到的疑问其实是很多刚接触依赖倒置和抽象工厂模式的开发者都会遇到的点，看似主方法还是要创建具体工厂，但FactoryService的价值体现在以下几个关键场景：

• 隔离实例创建的复杂逻辑
  如果ConcreteImpl的实例化需要多个依赖参数、配置项，甚至要根据环境（开发/测试/生产）做分支判断，这些逻辑都可以封装在FactoryServiceImpl里。主方法只需要简单创建工厂实例传入Application，不用关心ConcreteImpl是怎么造出来的。后续如果ConcreteImpl的创建逻辑变了，只改工厂类就行，Application和主方法的代码都不用动。

• 支持延迟或按需实例化
  如果Application不是在启动时就需要ConcreteImpl，而是运行过程中多次创建实例，或者根据业务条件动态创建不同实现，直接传一个预先创建好的ConcreteImpl就满足不了需求。通过FactoryService，Application可以在需要时调用create()方法获取实例，工厂类可以控制实例的创建时机、数量（比如单例或多实例）。

• 统一管理实现替换
  假设后续要把ConcreteImpl换成另一个实现NewConcreteImpl，或者在测试时用MockImpl，只需要新增一个NewFactoryServiceImpl或MockFactoryServiceImpl，然后在主方法里替换创建的工厂实例即可。所有依赖FactoryService的模块（比如Application）完全不需要修改，实现了真正的面向抽象编程，避免了代码中到处出现具体类的依赖。

• 强化模块独立性与可测试性
  Application依赖的是FactoryService接口，而非具体的工厂或实现类，这意味着Application的代码可以独立编译、测试，不用依赖ConcreteImpl的源码。写单元测试时，你可以轻松实现一个TestFactoryService，返回模拟的ConcreteImpl实例，而不用启动真实的依赖，大幅提升测试效率。

简单说，直接传ConcreteImpl只是解决了Application对具体类的依赖，但如果后续实现需要变化，或者创建逻辑复杂，这种方式会让代码变得僵硬。而抽象工厂模式通过多一层抽象，把"创建实例"的逻辑也封装起来，让整个系统的扩展性和维护性更上一个台阶。

内容的提问来源于stack exchange，提问作者rbansal