工厂模式核心是解决新增类型时修改已有代码的痛点,通过集中管理实例化过程实现开闭原则;简单工厂适用于同构对象创建,应避免if链而用注册机制,工厂只负责返回初始化对象。

工厂模式不是为了“设计得漂亮”,而是为了解决“新增类型时要改一堆已有代码”这个具体痛点。 它的核心价值在于把 class 的实例化过程从业务逻辑里抽出来,集中管理、按需分发——只要新增一个类 + 在工厂里注册一下,其他地方完全不用动。
什么时候该用简单工厂(而不是抽象工厂)
当你只有一组同构对象(比如都是 PaymentProcessor 子类),且创建逻辑不随平台/配置变化时,SimpleFactory 就够用。它本质是个带分支的函数,不是 GoF 严格意义上的“模式”,但最常用、最容易落地。
- 适用场景:支付方式切换(
AlipayProcessor/WechatPayProcessor)、日志输出格式(JsonLogger/TextLogger) - 常见错误:把工厂写成巨型
if-elif链,每次加新类型都要改工厂代码 → 应该用字典注册 + 动态导入 - 参数差异:
create_processor(payment_type: str)比create_processor(type_name: str, config: dict)更易维护,后者容易让工厂承担不该管的初始化逻辑
如何避免工厂变成新的上帝对象
工厂类膨胀的根源,是混入了对象初始化之外的责任,比如配置解析、连接池管理、策略路由。它只该做一件事:根据输入返回一个已初始化好的对象实例。
图片提示词生成器?不止如此。 马甲系统 —— 把脑海中的画面,翻译成AI能理解的专业表达。 用得越多,它越懂你:首次需要多问几句确认方向,用久了几乎一说就懂。 用得越多,它越快:缓存机制让后续对话越来越省。 RAG进化:成功案例持续入库,越跑越聪明。 输入「新手指南」查看完整功能介绍
- 性能影响:如果对象构造开销大(如建立数据库连接),工厂里不要直接
return SomeService(),改用lambda或partial延迟执行 - 兼容性注意:Python 3.9+ 可用
typing.Annotated标注工厂返回类型,但别在工厂内部做类型检查——那是调用方或 Pydantic 的事 - 正确做法示例:
class ProcessorFactory: _registry = {} @classmethod def register(cls, name: str): def decorator(klass): cls._registry[name] = klass return klass return decorator @classmethod def create(cls, name: str, **kwargs): klass = cls._registry.get(name) if not klass: raise ValueError(f"Unknown processor: {name}") return klass(**kwargs)
抽象工厂在 Python 里往往过度设计
抽象工厂解决的是“创建一系列相关对象”的问题(比如 Windows GUI 组件 vs macOS GUI 组件),但在 Python 中,这种需求极少。更多时候,你只是需要一个统一入口创建某类对象,SimpleFactory + 注册机制已经覆盖 95% 场景。
- 容易踩的坑:为“未来可能有多个产品族”提前写
WindowsFactory/MacFactory,结果半年后只用了一个;反而增加了理解成本 - 真实替代方案:用配置驱动,比如
config.yaml里定义processor: alipay,工厂读配置决定实例化谁,比硬编码工厂类更灵活 - 如果真遇到多产品族需求(如测试环境 mock 所有服务),优先考虑依赖注入容器(
dependency-injector库),而不是手写抽象工厂
工厂模式最难的部分不是写代码,而是判断“这个对象的创建逻辑是否真的值得封装”。很多所谓“扩展性问题”,其实只是没想清楚对象职责边界——先拆清类的单一职责,工厂自然就清晰了。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!










