工厂函数返回实例前不强制类型校验，但生产环境通常添加；校验应随类型注册而非硬编码在工厂中；简单工厂适合类型少、扩展少场景，抽象工厂适用于需强约束一族对象的场景；工厂应无状态，优先用@staticmethod实现。
工厂函数返回实例前要不要做类型校验
不强制，但多数生产环境会加。因为工厂的核心职责是解耦对象创建逻辑，不是兜底类型安全——如果下游代码依赖特定接口，应在调用处做 isinstance 或协议检查，而非让工厂替你拦住非法参数。
常见错误是工厂里写一堆 if type(arg) is X，结果新类型加进来就得改工厂；更灵活的做法是注册时绑定校验函数：
class Factory:
_creators = {}
_validators = {}
<pre class="brush:php;toolbar:false;">@classmethod
def register(cls, name, creator, validator=None):
cls._creators[name] = creator
if validator:
cls._validators[name] = validator
@classmethod
def create(cls, name, **kwargs):
if name not in cls._creators:
raise ValueError(f"Unknown product: {name}")
if name in cls._validators and not cls._validators[name](kwargs):
raise ValueError(f"Invalid config for {name}")
return cls._creators[name](**kwargs)
- 校验逻辑随类型注册走，新增产品不用动工厂主干
- validator 可以是 lambda，也可以是独立函数，便于单元测试
- 错误信息里带具体
name，比泛泛的TypeError更易定位
抽象工厂 vs 简单工厂，什么场景该选哪个
简单工厂（一个函数或类负责创建多种同类对象）适合配置驱动、类型不多且不常扩展的场景，比如日志处理器：get_logger_handler("file")、get_logger_handler("http")。
立即学习“Python免费学习笔记（深入）”；
抽象工厂（定义创建一族相关对象的接口，由子类实现）只在你明确需要「绑定约束」时才值得上——例如数据库模块既要支持 MySQL 又要支持 PostgreSQL，且每个库都必须配套自己的 Connection、Cursor、Transaction，这时用抽象工厂能防止混用：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
class DBFactory(ABC):
@abstractmethod
def create_connection(self): ...
@abstractmethod
def create_cursor(self): ...
<p>class MySQLFactory(DBFactory):
def create_connection(self): return MySQLConnection()
def create_cursor(self): return MySQLCursor() # 和上面强关联</p><h1>调用方拿到 factory 后，所有产出天然兼容</h1><p>- 抽象工厂增加了一层间接，调试时多跳一次，别为“看起来更规范”而用
- 如果只是换序列化格式（JSON/MsgPack/YAML），用简单工厂 + 策略模式更轻量
- Python 没有接口强制，靠文档和类型提示（
Protocol）维持族内一致性
工厂类该不该带状态（比如缓存已创建的实例）
带状态是反模式，除非你明确在做对象池或单例变体。标准工厂应是无状态的：输入相同参数，每次返回新实例。否则会引发隐式共享、线程不安全、测试难 mock 等问题。
如果真需要复用（如连接池、配置解析器），应该拆成两个角色：
- 工厂：纯创建，
create_pool(size=10) - 管理器：持有并复用，
PoolManager.get_or_create("default")
强行把两者塞进一个类，很快会出现「这个方法该清缓存吗」「并发调用会不会覆盖缓存」这类纠结。
用 @staticmethod 还是 @classmethod 实现工厂方法
优先 @staticmethod。工厂方法本质是命名空间下的函数，不依赖类本身的状态或继承链。用 @classmethod 的唯一合理理由是：你需要子类能重载它并访问 cls（比如自动根据子类名推导配置路径）。
但要注意：Python 的 cls 是运行时确定的，如果父类工厂被子类继承后没重写方法，cls 仍是子类——这容易导致意外行为：
class BaseFactory:
@classmethod
def create(cls, **kw):
print(f"Creating for {cls.__name__}") # 这里 cls 是调用者，不是定义者
return cls._impl(**kw)
<p>class UserFactory(BaseFactory):
pass</p><p>UserFactory.create() # 输出 "Creating for UserFactory"，不是 "BaseFactory"
- 静态方法语义清晰，不引入继承歧义
- 需要动态行为时，显式传入类或使用注册表，比依赖
cls更可控 - IDE 和类型检查器（如 mypy）对
@staticmethod的推断也更稳定
工厂最难的从来不是怎么写，而是什么时候该删掉它——当注册项超过 5 个、配置开始嵌套、同事开始问“这个 new_xxx 函数到底在哪定义的”，就该回头看看：是不是把简单问题过度架构了。
