Python OOP设计：用协议优于继承，告别脆弱基类

在 Python 里写 OOP最容易踩的坑之一就是“拿到继承就当万能膏药”。学设计模式的时候被灌输“继承复用父类方法”写业务代码时也习惯从某个基础类派生出一堆子类。直到某天你发现改了一个父类十几个子类行为跟着变或者为了给某个类“塞进”现有体系不得不伪造一整套血缘关系才意识到这条路不对。这期“Python OOP 设计思想 09”我想聊一个比“组合优于继承”更贴合 Python 气质的原则协议优于继承。这里的“协议”不是网络协议而是 Python 里基于特殊方法dunder method形成的行为约定——比如实现了__len__就能被len()接收、实现了__iter__就能被for遍历。核心观点很简单我们要让对象通过“具备某种行为”而融入生态而不是通过“继承某位祖先”而获得身份。如果你正处于“面向对象写过一两年、但总觉得代码越改越脆”的阶段这篇内容会从机制到实战完整过一遍把为什么要协议优先、怎么识别协议、怎么用抽象基类和typing.Protocol把协议固化下来以及我实际踩过的坑都讲清楚。1. 协议优于继承到底在说什么1.1 继承的“复用红利”和隐藏负债先用最熟悉的例子展开。你写一个Animal类里面有eat()和sleep()然后让Dog、Cat继承它。前期很爽子类自动拿到了父类的方法代码看起来少了一半。可项目跑一段时间后问题就来了某天产品要求在Animal上加一个fly()能力你也许觉得“反正子类可以覆盖”但事实是父类每动一次所有子类的行为都可能受影响哪怕子类根本不该有翅膀。这就是经典的脆弱基类问题brittle base class。继承建立的是一种强耦合关系子类不仅依赖父类的公开接口还悄悄依赖它的内部实现。更隐蔽的是命名冲突——父类新增的某个方法或属性恰好和子类已有的名字撞了子类会在自己不知情的情况下改变行为这类 bug 定位起来极其痛苦。另一个容易被忽略的成本是测试。一旦继承层级变深你想单独测某个子类就得先初始化一整条继承链上的依赖。为了复用两个方法结果绑定了父类里一堆你不关心的状态。这就像为了用一把螺丝刀买下了整间工具箱还得替它付房租。1.2 Python 里的“协议”到底是什么Python 社区常说的“协议”指的是一组特殊方法dunder method的名称和调用约定。语言内建函数和语法糖会按照这些约定去调用对象的方法而不关心对象的实际类型。比如len(obj)实际上调用的是type(obj).__len__(obj)for x in obj会优先尝试obj.__iter__()拿到迭代器后不断调__next__()with obj as f会调用obj.__enter__()和obj.__exit__(...)obj[key]会调用obj.__getitem__(key)obj1 obj2会调用obj1.__add__(obj2)如果一个对象实现了某个协议要求的特殊方法Python 就认为它“有能力”参与这种语法。这就像 USB 接口你的设备内部是什么样的无所谓只要实现了 USB 协议、插上就能用。你不需要继承一个“USB 设备基类”厂商也不需要先问“你爸是谁”大家遵守同一套约定就通了。所以“协议优于继承”的第一层含义是复用一个能力应该靠实现行为约定而不是靠攀血缘关系。让一个类可迭代你应该写__iter__而不是继承list让一个类支持with你应该写__enter__和__exit__而不是继承某个ContextManager基类。2. 协议的底层机制特殊方法与鸭子类型2.1 特殊方法组合成的那些“接口”Python 官方文档里其实没有一张完整的“协议总表”但多年实践下来每个 Python 开发者脑子里都有这么一张常用清单。我整理了一份后文讨论都会用到协议名称涉及的特殊方法触发场景可迭代协议__iter__、__getitem__for循环、sum()、list()等迭代器协议__iter__、__next__next(obj)、for循环驱动序列协议__len__、__getitem__、__setitem__obj[i]、切片、in判断上下文管理器协议__enter__、__exit__with obj as f:数值运算协议__add__、__sub__、__mul__等、-、*运算符哈希与相等协议__hash__、__eq__放入dict、set描述符协议__get__、__set__、__delete__类属性访问控制转换协议__str__、__repr__、__int__str(obj)、print(obj)只要某个类实现了上面某一行的特殊方法它就能无缝接入对应场景。我经常在项目里写一些“轻量容器”实现__len__、__getitem__、__iter__之后这个类立刻能被sum()计算、被for遍历、被in判断、被random.choice()选中。整个过程不需要继承任何集合类外面传参的人也完全不关心它内部是哪种存储结构。来看一段具体的演示代码class RangeView: def __init__(self, start, end, step1): self._items list(range(start, end, step)) def __len__(self): return len(self._items) def __getitem__(self, index): return self._items[index] def __iter__(self): return iter(self._items) def __contains__(self, item): return item in self._items r RangeView(1, 10, 2) print(len(r)) # 5 print(3 in r) # True print([x * 2 for x in r]) # [2, 6, 10, 14, 18] print(r[1:3]) # [3, 5]RangeView没有继承list也没有继承Sequence但它就是能和“序列”相关的语法配合得很好。这就是协议带来的弹性你不需要承诺“我是 list”只需要承诺“我有 list 同款行为”。2.2 为什么 Python 运行时偏爱协议从解释器实现角度看Python 在语法层面对特殊方法的查找是直接走类型的方法表的比沿着一棵继承树逐层找要直接得多。更重要的是协议让不同库之间的协作不需要提前商量好“谁是父类”。标准库里到处都是这种设计。sorted()接受任何可迭代对象不管它是list、tuple、dict的 key 视图还是你自己写的类json.dumps()能序列化任何支持__iter__或映射协议的对象heapq的堆操作函数接收的也只是一个列表对象只要你遵守“列表元素可比较”的约定即可。这种设计带来的直接好处是你不需要为了被某个库识别去继承那个库里的某个类。库作者只要面向协议编程就能覆盖所有实现相同协议的对象哪怕这些对象来自互不相识的第三方库。我们开发业务代码时也应该这样——函数参数按协议声明而不是按具体类名声明。2.3 虚拟子类协议与继承之间的“官方后门”既然协议是行为约定那isinstance(obj, 某个抽象基类)这种检查又该怎么处理Python 给出了一个很巧妙的设计虚拟子类virtual subclass机制。抽象基类ABC可以通过register()方法把一个类登记为自己的“虚拟子类”。登记之后isinstance()和issubclass()都会返回True但那个类实际上并没有继承这个 ABC也不需要实现它的任何方法。from collections.abc import Mapping class MyDictWrapper: def __getitem__(self, key): return {a: 1}[key] def __len__(self): return 1 def __iter__(self): return iter([a]) def __contains__(self, key): return key a # 不需要继承 Mapping也能登记为 Mapping Mapping.register(MyDictWrapper) print(isinstance(MyDictWrapper(), Mapping)) # True这是协议优于继承的又一体现即使你面对的是一个已经写死、不能改动源码的类只要它具备了协议要求的行为你就能通过register()让它“被认作”协议家族的一员。血缘关系不再重要能力说了算。3. 面向协议编程的日常组合之外的第三条路3.1 “组合优于继承”为什么还不够很多同学已经听过“组合优于继承”Composition over Inheritance会用“把一个对象塞进另一个对象”的方式来替代继承。这当然是对的但它属于所有面向对象语言的通用方案——Java、C 里同样适用。而“协议优于继承”是 Python 特有的一条扩展。它强调的不是“用组合替代继承”而是把能力定义在接口和行为层面。有些时候你甚至不需要显式组合某个对象只要实现对应特殊方法就能拥有某种能力。举个例子你需要一个“只读字典视图”类。组合方案是内部持有一个dict对象再手动暴露查询方法。协议方案则是直接实现Mapping协议所需的__getitem__、__iter__、__len__方法立刻就能被所有接受“映射”的函数使用连“组合”这一步都省了。class ReadOnlyView: def __init__(self, data: dict): self._data data def __getitem__(self, key): return self._data[key] def __iter__(self): return iter(self._data) def __len__(self): return len(self._data) view ReadOnlyView({name: python, version: 3.12}) print(dict(view)) # 能转成普通 dict print(name in view) # 能走 in 判断这里ReadOnlyView可以被传入任何接受“映射协议”的地方而且存储结构可以随时替换不影响对外行为。这种灵活性继承做不到也比较难用组合达到同样优雅。3.2 面向协议写代码的四个习惯在业务代码里落实“协议优于继承”我总结了四个可操作的习惯你可以直接用到下一次编码中。习惯一参数按协议声明不按具体类型声明。写函数时优先用Iterable、Mapping、Callable这类协议类型做注解而不是写死list或dict。这能让调用方传任何满足协议的对象进来。from typing import Iterable def calculate_total(items: Iterable[float]) - float: return sum(items) # 能传入 list、tuple、生成器、自定义可迭代对象习惯二扩展能力靠实现协议不靠给父类加方法。想让一个类支持比较就实现__lt__、__eq__而不是给它的父类强行塞一个compare_to想让一个类支持上下文管理就写__enter__、__exit__。这样类与类之间互不打扰各自具备能力。习惯三用协议检查替代类型判断。少写isinstance(obj, list)多用isinstance(obj, collections.abc.Sequence)或直接依赖鸭子类型。前者检查的是“你是不是某个具体类”后者检查的是“你有没有某类行为”。习惯四用Protocol定义业务侧的“行为接口”。当一段逻辑需要约束“有名字、能展示”的对象时定义一个Named协议类而不是定义一个BaseModel基类让所有东西去继承。这个点在第 4 节展开。4. 用抽象基类和 typing.Protocol 把协议显式化4.1 collections.abc可检查、可注册的协议字典上节我们一直在说“协议”但协议毕竟是隐性的代码里怎么明确表达答案在collections.abc模块。它提供了Iterable、Iterator、Sequence、Mapping、Collection等抽象基类其实就是把协议“官方化”了。你完全不必继承它们但可以用它们做检查from collections.abc import Sequence class MyList: def __getitem__(self, index): return [1, 2, 3][index] def __len__(self): return 3 print(isinstance(MyList(), Sequence)) # True print(isinstance(MyList(), Iterable)) # Trueisinstance(obj, Iterable)会比hasattr(obj, __iter__)更可靠。因为Iterable的__subclasshook__会检查对象是否实现了__iter__同时register()的虚拟子类也会被认可。这一层抽象让“协议检查”有了统一入口。但这里有一个使用要点collections.abc里的抽象基类并不是用来强制继承的它们更像一本“行为说明书”。继承它们通常只是为了省下实现默认方法的工作量比如继承MutableSequence时你只需要实现__getitem__、__setitem__、__len__、insert、delitem其余append、pop、extend等都会基于你实现的方法自动补全。这仍然是“面向协议”的因为你继承的是协议骨架而不是业务身份。4.2 typing.Protocol让静态检查也认协议Python 3.8 引入的typing.Protocol把“协议优于继承”从运行时推进到了静态类型检查层。它的核心思路是结构化子类型structural subtyping你定义一个协议类只要某个类在结构上满足协议的要求它就是协议的子类型哪怕它完全没有继承关系。from typing import Protocol class Named(Protocol): name: str def display_name(self) - str: ... class User: def __init__(self, name: str): self.name name def display_name(self) - str: return f用户{self.name} def show(obj: Named) - str: return obj.display_name() u User(张三) print(show(u)) # 运行时没有任何问题这段代码里User并没有继承Named但因为有name属性和display_name()方法mypy 和 Pyright 都会认为User满足Named协议。这带来的好处是巨大的你可以在大型项目里用Protocol定义模块之间的“契约”各模块独立实现、互不继承但类型检查器依然能帮你找出不满足契约的调用。用Protocol做业务接口时我建议给它加上文档字符串写清楚“实现这个协议需要哪些方法、这些方法应该满足什么行为”。因为Protocol类型在运行时不会拦截错误它更像代码评审的一部分靠工具链保证约束。class Closeable(Protocol): 可关闭资源协议。实现 close() 且在多次调用时安全。 def close(self) - None: ...4.3 继承依然存在的位置模板方法与协议骨架讲了这么多协议的好处我要明确一点并不是让你把所有继承都废掉。继承在两种场景下依然非常合理。第一种是模板方法模式。框架父类定义算法骨架子类实现某些步骤。比如你写一个数据处理基类process()方法已经规定好“读取、清洗、计算、输出”的顺序子类只需要覆盖clean()或compute()。这时候父类是被精心设计为“部分实现”的子类继承的是一套流程而不仅仅是散装方法。第二种是继承协议骨架。前面提到的collections.abc.MutableSequence就是典型它已经基于你实现的核心方法生成了一批默认方法。继承它的目的不是获取“身份”而是复用协议自带的默认实现。所以从某种意义上说这也符合“协议优于继承”——你继承的是协议本身不是某个业务对象的血脉。判断标准很简单如果基类代表的是“你是什么”如Animal、Vehicle用继承就很容易陷入脆弱的层级如果基类代表的是“你能做什么”如Iterable、Closeable继承它就是合理的协议复用。5. 常见问题与排查技巧实录5.1__len__返回负数或非 intlen()直接报错len()对__len__的返回值有硬性要求必须是非负整数。常见坑有两个。一个是误把布尔值当返回值写布尔在 Python 里虽然是int子类但语义不对另一个更隐蔽——用 NumPy 数组的长度时np.int64类型在很多 Python 版本里不会被len()接受会抛TypeError: numpy.int64 object cannot be interpreted as an integer。排查思路是先在方法里打印返回值的类型print(type(self._data))。如果发现是np.int64就手动转成int(len(self._data))。这是一个非常经典的隐性协议违约案例因为它们长得像整数但协议不认。5.2 只实现__getitem__也能 for但行为很怪Python 迭代协议其实有两条路实现了__iter__就走迭代器协议没有__iter__但实现了__getitem__解释器会通过索引 0、1、2……依次取值直到抛出IndexError。这意味着一个类如果只实现__getitem__也能被for循环遍历。但如果不小心让__getitem__对非整数索引也返回了值比如obj[-1]有业务含义那么循环可能越界或产生奇怪的顺序。更麻烦的是只靠__getitem__的对象在很多库里的处理效率很低比如in判断会逐个索引取值而不是用__contains__。所以排查循环异常时先看一眼类里有没有__iter__。没有就补上有但行为不对就检查__next__的停止条件是不是抛了StopIteration。5.3with语句里__enter__忘了返回值这是我在 code review 里见过最多次的协议坑。很多人写上下文管理器时只关心__enter__里要做什么准备工作、__exit__里要做什么清理工作完全没注意到__enter__的返回值会被with ... as绑定。class Resource: def __enter__(self): self._setup() # 这里忘了 return self def __exit__(self, exc_type, exc_val, exc_tb): self._cleanup() with Resource() as r: print(r) # 永远是 None协议要求__enter__返回上下文对象本身或任意你想要暴露的对象。排查这类问题时第一件事就是在with里打印进入时拿到的是什么如果一直是None回去检查__enter__有没有return self。5.4isinstance误判和虚拟子类带来的“虚假安全感”register()虽然好用但它有一个副作用isinstance(obj, SomeABC)返回True不代表obj真的有了SomeABC定义的方法。它只代表“这个类被登记过请把它当亲戚看”。如果代码里基于isinstance的结果去调用父类方法就会在运行时报AttributeError尤其当被登记的类混入第三方库、后续版本接口变化时这种问题更难发现。另外静态类型检查器默认不感知register()的虚拟子类关系。你在运行时靠Mapping.register(MyClass)让isinstance通过了但 mypy 并不知道这件事会继续报类型错误。如果确实需要运行时检查和静态检查同时通过可以使用typing.TYPE_CHECKING分支做额外断言或者在 mypy 配置里加对应插件。这里不建议写太多高级技巧但至少要意识到“运行时”和“静态检查”检查的是两套信息。最后分享一个我在实际项目中的体会。前两年重构一个数据同步模块原代码用三层继承组织基类是“同步器”中间是“数据库同步器”最下面是“MySQL同步器”和“PostgreSQL同步器”。每加一种新数据库就要新增一个子类还要担心中间层的改动影响所有方言。后来我把公共能力拆成几个协议SourceReader负责读取、Transform负责转换、SinkWriter负责写入各实现类只实现协议靠组合装配流水线。重构完单元测试好写了mock 只需要按协议伪造对象新增数据库也只需要新写一个SinkWriter实现完全不碰其他代码。我自己的经验是每当你准备写“继承某个类来获得它的方法”时先停下来问一句这个能力是身份还是行为如果是行为优先用协议。这个简单的提问能帮你在绝大多数场景下做出更 Pythonic 的类设计。