Python工厂设计模式疑问：Creator类的必要性探讨

你的疑问很关键——只要Creator类的职责仅聚焦于产品的创建逻辑，就不会违反单一职责原则，同时相比直接传入Product的实现，它能带来这些实实在在的好处：

• 封装产品创建的细节
  如果ConcreteProduct的实例化需要复杂的参数配置、依赖注入或者初始化步骤（比如ConcreteProduct1需要传入数据库连接、配置文件路径），把这些逻辑放在ConcreteCreator里，Client代码完全不用关心。此时ConcreteCreator的唯一职责就是创建对应Product的实例，完全符合单一职责。而直接传Product的话，Client必须自己处理这些创建细节，耦合度极高。

• 解耦Client与具体产品的依赖
  Client只依赖Creator抽象，不需要知道具体是ConcreteProduct1还是ConcreteProduct2。如果后续要新增ConcreteProduct3，只需要新增对应的ConcreteCreator3，Client代码完全不用修改。而直接传Product的话，Client必须显式实例化具体产品，每次新增产品都要改动Client的实例化代码。

• 统一产品创建的规范与流程
  Creator抽象定义了工厂方法的标准接口，所有ConcreteCreator都遵循这个接口实现产品创建。这能避免不同业务场景中创建同一种Product的方式不一致（比如有的地方给Product传了参数A，有的地方没传）。此时Creator的职责就是提供标准化的产品创建入口，单一且明确。

• 支持灵活的创建时机控制
  比如业务需要在调用some_operation时才创建Product（而不是一开始就传入），Creator可以轻松实现这种延迟创建逻辑。这种情况下Creator的职责是管理产品的创建时机，属于创建逻辑的一部分，不违反单一职责。而直接传Product的话，产品必须提前实例化，无法灵活控制创建时机。

需要明确的是：如果在factory_method里添加和产品创建无关的逻辑（比如发送业务通知、处理用户请求），那确实会违反单一职责，但这是使用方式的问题，不是模式本身的问题。只要Creator始终专注于“创建产品”这一件事，就完全符合单一职责原则。

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