17370845950

鸭子类型强调对象“能做什么”而非“是什么”，Python 接口设计转向协议（Protocol）与文档约定，依赖行为契约、测试验证和轻量适配，兼顾动态性与可维护性。

鸭子类型不依赖显式接口声明，而是关注对象“能做什么”，这直接改变了 Python 中接口设计的思路：不是定义“

接口设计从抽象类转向协议与文档约定

在强类型语言中，接口常通过抽象基类（ABC）强制实现；Python 更倾向用 typing.Protocol 描述行为契约，或干脆靠文档+测试来明确预期。例如，一个函数期望接收“可迭代对象”，它不检查是否是 list 或 tuple，只调用 iter()——只要对象实现了 __iter__，就符合接口。

• 用 Protocol 显式声明最小行为集（如 class Drawable(Protocol): def draw(self) -> None: ...），类型检查器能验证，运行时仍保持动态性
• 避免为兼容而继承 ABC，除非真需运行时检查（如 isinstance(obj, Iterable)）
• 关键方法名和参数意图比类型注解更重要——save() 应隐含“持久化当前状态”，而非仅满足签名

函数参数更注重行为兼容，而非类型继承

设计函数时，优先考虑“这个参数会被怎么用”，再反推所需方法。比如一个日志记录函数 log(message, formatter)，它只调用 formatter.format(message)，那 formatter 只需有 format 方法即可，不必是某个 Formatter 类的实例。

• 写 docstring 时明确写出“期望参数支持 .read()、.close() 方法”比写“类型为 file-like object”更准确
• 用 hasattr() 或 getattr(..., None) 做轻量适配，比提前 isinstance() 判断更符合鸭子类型精神
• 允许传入函数、lambda 或带方法的简单对象（如 types.SimpleNamespace(format=lambda x: x.upper())）

测试驱动接口边界，而非类型系统约束

由于没有编译期类型检查，接口的“契约完整性”更多靠测试保障。一个符合接口的对象，必须通过一组针对其行为的单元测试。

• 为协议编写独立测试用例（如测试任意 Drawable 实现能否被 render() 正确调用）
• 使用 pytest.mark.parametrize 覆盖多种鸭子类型实现（dict-like、list-like、自定义类）
• 当发现某类对象“几乎可用但缺一个方法”时，优先加适配逻辑或文档说明，而非要求用户改继承关系

向后兼容更容易，但隐式契约更难发现

鸭子类型让添加新实现变得简单——只要满足已有方法签名，老代码无需修改就能用。但这也带来风险：接口变更（如新增必需方法）不会报类型错误，只会在运行时报 AttributeError。

• 重大行为变更时，在文档中明确标注“此版本起要求支持 .flush() 方法”
• 在关键入口处加防御性检查（如 if not hasattr(obj, 'write'): raise TypeError("obj must support write()")），提升错误可读性
• 配合 mypy + Protocol 使用，把部分契约搬到编辑器提示层，兼顾灵活性与安全性

鸭子类型让接口更轻量、扩展更自然，代价是契约更隐性。好的 Python 接口设计，是在文档清晰、测试充分、类型提示适度辅助之间找平衡。