前言面向接口编程programming to an interface的核心主张是调用方应该依赖能做什么而不是依赖是谁。这样换实现时不必改调用方测试时也容易塞进一个假的实现。在 Java 里接口是一个明确的语法结构interface。Python 没有这个关键字所以初学容易困惑Python 到底有没有接口答案是有接口这个思想但落地方式不止一种。本文讲三种从松到紧排列鸭子类型duck typing——完全靠约定不写任何声明抽象基类ABC——用abc显式声明必须实现什么协议类Protocol——用typing.Protocol描述结构配合静态类型检查器做静态鸭子类型。常见的误解是用 Python 就得全靠鸭子类型类型检查没必要或者反过来必须像 Java 一样先定义接口才能写代码。实际情况是这三者可以按需要叠加本文给出选择标准和可直接运行的示例。一、接口在两处起作用运行时和静态检查要理解 Python 的接口先分清两个层面运行时接口体现为对象上有没有这个方法/属性。有就能调没有就AttributeError。这层由鸭子类型覆盖。静态检查时接口体现为类型检查器如 mypy能看懂的结构声明。这层由typing.Protocol覆盖。ABC 同时作用于两处运行时会拦住未实现完整的子类实例化静态检查器也能读懂继承关系。二、方式一鸭子类型最轻量的写法是压根不声明接口直接在函数里调用方法# 适用于 Python 3.8def total_price(items):return sum(item.price for item in items)class Book:def __init__(self, price):self.price priceclass Course:def __init__(self, price):self.price priceprint(total_price([Book(30), Course(199)])) # 229total_price只要求元素有.price不问类型。这就是面向接口——接口就是.price这个属性名只不过它是隐式的。它的优点是零样板、极其灵活缺点是接口没有被写下来改错了要到运行时才发现。三、方式二抽象基类ABC当需要必须实现的硬约束时用abc.ABC加abstractmethod# 适用于 Python 3.8from abc import ABC, abstractmethodclass Notifier(ABC):abstractmethoddef send(self, message):...class EmailNotifier(Notifier):def send(self, message):return f邮件{message}class SmsNotifier(Notifier):def send(self, message):return f短信{message}好处是任何忘了实现send的子类一实例化就抛TypeError同时Notifier 是一种接口这件事在代码里写得明明白白。代价是强耦合到继承关系——想让一个已有的、不能改继承结构的类满足Notifier只能靠Notifier.register(那个类)而虚拟子类只影响类型判定拿不到方法实现。四、方式三Protocol结构化子类型typing.Protocol需要 Python 3.8 及以上表达的正是鸭子类型的静态版本只要一个类的形状有哪些方法和属性符合协议就被视为这个协议的子类型不需要显式继承。# 适用于 Python 3.8from typing import Protocolclass SupportsClose(Protocol):def close(self) - None:...def shutdown(obj: SupportsClose) - None:obj.close()这里SupportsClose只描述有个close方法任何有这个方法的类都能传给shutdown类型检查器会认运行时不报错。这就是文档所说的结构化子类型structural subtyping。默认情况下Protocol不能用于isinstance()或issubclass()。要让它能在运行时的类型检查里用得加上runtime_checkable# 适用于 Python 3.8from typing import Protocol, runtime_checkableruntime_checkableclass Named(Protocol):name: strclass Person:def __init__(self, name):self.name nameprint(isinstance(Person(a), Named)) # True有三条关于runtime_checkable的限制必须记住它只检查需要的成员是否存在不检查类型签名或属性类型。名字对上了就算通过。文档提示对 runtime-checkable 协议做isinstance检查比普通类慢热点路径上考虑改用hasattr。从 Python 3.12 起检查内部改用inspect.getattr_static()查属性此前用hasattr()少数对象的结果可能与 3.12 之前不同。五、把接口用于依赖注入面向接口编程最大的收益是让依赖谁变成可替换的。用一个完整例子收尾Report依赖一个能写入的对象而不是某个具体类。# 适用于 Python 3.8from typing import Protocolclass Writer(Protocol):def write(self, text: str) - None:...class ConsoleWriter:def write(self, text: str) - None:print(text)class ListWriter:def __init__(self):self.lines []def write(self, text: str) - None:self.lines.append(text)class Report:def __init__(self, writer: Writer): # 依赖接口不依赖具体类self._writer writerdef render(self, title):self._writer.write(f# {title})Report(ConsoleWriter()).render(日报)buf ListWriter()Report(buf).render(周报)print(buf.lines) # [# 周报]换输出目标时Report一个字都不用改——这就是面向接口的价值。三种方式的取舍方式需要声明吗运行时强制静态检查适用场景鸭子类型否否否小脚本、内部工具抽象基类 ABC是继承或注册是实例化时是需要硬约束的框架代码Protocol是描述结构仅在加runtime_checkable时是结构化、不侵入现有类常见坑点1. 依赖具体类而不是接口❌Report.__init__(self, writer: ConsoleWriter)换个输出方式就得改Report。✅ 参数类型写成协议或 ABC任何满足形状的对象都能注入。2. 给 Protocol 加isinstance却忘了runtime_checkable❌ 没加装饰器就isinstance(obj, MyProtocol)直接抛TypeError。✅ 需要运行时结构检查时加上runtime_checkable。3. 以为runtime_checkable会校验签名❌ 以为方法参数类型不对会被拦下。✅ 它只检查成员是否存在类型签名完全不看。4. 以为Protocol的成员会自动提供实现❌ 在协议里写了def close(self): ...就以为子类会自动有这个方法。✅ 协议只是形状描述省略号是占位不提供任何行为。5. 把 ABC 用成为了类型检查而继承❌ 每个类都硬塞一个 ABC 父类只为通过类型检查结果继承链被污染。✅ 只想做静态结构检查时用 Protocol不侵入类的继承关系。6. 在热点路径上对 protocol 频繁做isinstance❌ 以为它和普通isinstance一样快。✅ 文档明确说它更慢性能敏感处用hasattr或把检查提到循环外。7. 让接口变得太大❌ 一个协议里塞了十几个方法任何实现都很难满足。✅ 接口要小而内聚通常一两个方法需要多项能力就拆成多个协议组合。8. 用type(x) SomeClass做接口判定❌ 漏掉子类与虚拟子类判定结果和isinstance不一致。✅ 需要判定时用isinstance(x, SomeABC)或干脆不做判定、直接调用。总结要点结论接口的本质能响应哪些方法而非是不是某个类默认风格鸭子类型只调用方法不做类型检查需要硬约束用abc.ABCabstractmethod需要静态结构检查用typing.Protocol3.8需要运行时协议检查加runtime_checkable只查成员存在性最大收益依赖抽象实现可替换测试可注入替身面向接口编程在 Python 里不是要不要写 interface 关键字的问题而是调用方依赖的是行为还是具体类型的问题。写完一个函数后问自己一句它记住的是某个类的名字还是某个方法的名字答案若是后者你已经在面向接口编程了。