我要评论接口与抽象基类
在面向对象的世界中，我们应该对接口编程，而不是实现。我们的代码应该依赖于对象能做什么（抽象），而不是对象具体是谁（具体实现）。
下面通过吃汉堡的例子来演示一下。
依赖具体实现
class bigmac:
def eat(self):
return "巨无霸：双层牛肉，酱汁浓郁！"
class chickenburger:
def eat(self):
return "香辣鸡腿堡：外酥里嫩！"
class human:
def eat_lunch(self, food: bigmac):
# 【面向实现编程】
# 这里写死了：我只检查是不是巨无霸。
# 如果想吃香辣鸡腿堡，必须修改 human 类的代码！没有任何拓展性
if isinstance(food, bigmac):
print(f"人类正在吃: {food.eat()}")
else:
print("人类拒绝进食：这不是巨无霸！")
# --- 代码运行 ---
person = human()
mcd = bigmac()
kfc = chickenburger()
# 一旦换了不同的汉堡（具体实现）就吃不了了。。。
person.eat_lunch(mcd)
person.eat_lunch(kfc)通过上面的例子可以看到，一旦要换不同具体实现的汉堡，就必须修改人类的代码。
面向接口编程实现依赖倒置
from abc import abc, abstractmethod
# 1. 定义接口，这是汉堡基类，可以实现出不同的汉堡
class burger(abc):
@abstractmethod
def eat(self):
pass
# 2. 具体实现（必须继承 burger）
class bigmac(burger):
def eat(self):
return "巨无霸：双层牛肉！"
class chickenburger(burger):
def eat(self):
return "香辣鸡腿堡：脆皮炸鸡！"
# 3. 客户端
class human:
# 【面向接口编程】后续想挑战什么汉堡都可以，继承burger实现eat就可以
# 只要是 burger 的子类，我都能接受
def eat_lunch(self, food: burger):
print(f"人类正在吃: {food.eat()}")
# --- 代码执行 ---
person = human()
person.eat_lunch(bigmac())
person.eat_lunch(chickenburger())通过上面的代码可以看到，我们使用了abc写了一个抽象基类burger，对于类human的eat_lunch方法只是依赖了burger，而不是依赖了具体某个诸如chickenburger的实现类。后续human想要吃别的汉堡，我们一行代码都不需要改，只需要继承基类，然后实现具体的类就可以了，这就是依赖倒置！
而这种使用抽象基类实现依赖倒置的方式，是一种硬契约！
python中的类型检查
请注意，在python中的类型注解并不会强制检查，而只是一种静态检查，python解释器不会去理会参数的类型注解。
from abc import abc, abstractmethod
# 1. 定义接口，这是汉堡基类，可以实现出不同的汉堡
class burger(abc):
@abstractmethod
def eat(self):
pass
class dumpling(object):
def eat(self):
return "玉米饺子"
# 3. 客户端
class human:
# 【面向接口编程】后续想挑战什么汉堡都可以，继承burger实现eat就可以
# 只要是 burger 的子类，我都能接受
def eat_lunch(self, food: burger):
print(f"人类正在吃: {food.eat()}")
# --- 代码执行 ---
person = human()
# 传入的对象是饺子的实例对象，但是也可以运行成功，因为饺子有eat方法
person.eat_lunch(dumpling())可以看到，即使上面传入的不是显式继承汉堡基类的实例，也可以成功运行。因为类型注解只是静态检查。如果我们想要运行时检查，就得使用isinstance()显式检查。
from abc import abc, abstractmethod
# 1. 定义接口，这是汉堡基类，可以实现出不同的汉堡
class burger(abc):
@abstractmethod
def eat(self):
pass
class dumpling(object):
def eat(self):
return "玉米饺子"
# 3. 客户端
class human:
# 【面向接口编程】后续想挑战什么汉堡都可以，继承burger实现eat就可以
# 只要是 burger 的子类，我都能接受
def eat_lunch(self, food: burger):
if not isinstance(food, burger):
raise typeerror(f"必须传入 burger 的子类，当前传入的是: {type(food).__name__}")
print(f"人类正在吃: {food.eat()}")
# --- 代码执行 ---
person = human()
person.eat_lunch(dumpling())虚拟子类
但是这样做，其实也可以通过骚操作绕过去——虚拟子类
from abc import abc, abstractmethod
# 1. 定义接口，这是汉堡基类，可以实现出不同的汉堡
class burger(abc):
@abstractmethod
def eat(self):
pass
# 注册为汉堡的虚拟子类
@burger.register
class dumpling(object):
def eat(self):
return "玉米饺子"
# 3. 客户端
class human:
# 【面向接口编程】后续想挑战什么汉堡都可以，继承burger实现eat就可以
# 只要是 burger 的子类，我都能接受
def eat_lunch(self, food: burger):
if not isinstance(food, burger):
raise typeerror(f"必须传入 burger 的子类，当前传入的是: {type(food).__name__}")
print(f"人类正在吃: {food.eat()}")
# --- 代码执行 ---
person = human()
person.eat_lunch(dumpling())上面代码通过把饺子注册为汉堡的虚拟子类，代码可以跑通。
但是，从纯粹的面向对象理论来看，频繁使用普通类去进行 isinstance() 检查，确实在很大程度上违背了 python 核心的“鸭子类型”（duck typing）设计哲学。在python中其实并不怎么关注血统，更在意的其实是能力。
协议
在计算机世界里面，在不同语境下的协议具有不同的意思。比如我们最熟悉的http这种网络协议指明了客户端可向服务器发送的命令，例如get，put，post。而python中的对象协议则指明了为履行某个角色，对象必须实现哪些方法。协议相对于上面展示的面向接口编程，其实是更高层级的抽象，完美诠释了鸭子类型的设计哲学，只关注对象拥有什么能力，而不是去关注血统（父子类显式继承）。
一个展示python协议神奇之处的例子：
from collections.abc import iterable
class myiter:
# myiter类只是定义了__iter__方法
def __iter__(self):
pass
counter = myiter()
# 神奇的事情发生了，myiter和iterable并没有任何显式继承的关系
print(isinstance(counter, iterable))
# 验证一下myiter并没有继承iterable
print(myiter.__mro__)如果不熟悉python的读者一定会对代码的结果感到惊讶，明明myiter和iterable并没有任何显式继承的关系，但是isinstance(counter, iterable)居然返回了ture！这就是python协议的强大之处，目标有__iter__（迭代）的能力，我就认为你是一个迭代器，无需任何显式继承。
上下文管理器协议（context manager protocol）
python 的协议（protocol）打破了接口的最后一道枷锁——显式继承。它告诉我们，最高级的抽象不是去画一张完美无缺的物种分类图，而是去定义一套纯粹的行为契约。
# 1. 一个正经的后端对象：数据库连接
class databaseconnection:
def __enter__(self):
print("🔗 [database] 开启数据库连接...")
return self
def __exit__(self, exc_type, exc_val, exc_tb):
print("🔌 [database] 释放数据库连接...")
return false
# 2. 一个毫不相干的奇葩对象：魔法传送门
class magicalportal:
def __enter__(self):
print("🌀 [portal] 念动咒语，打开时空传送门...")
return self
def __exit__(self, exc_type, exc_val, exc_tb):
print("💥 [portal] 传送结束，关闭传送门防止怪物入侵...")
return false
# 3. 见证协议的威力
print("--- 场景 a：后端工程师在工作 ---")
# with 语句根本不在乎你是数据库还是什么，它只看协议
with databaseconnection():
print(" 执行 sql 查询: select * from users")
print("\n--- 场景 b：法师在施法 ---")
# 魔法传送门没有继承任何基类，但它满足了协议，照样能用 with！
with magicalportal():
print(" 正在穿越到艾泽拉斯大陆...")通过上面的例子（ai写的）可以看出，两个上下文管理对象没有任何显式继承，但是却能被with这个上下文管理器。原因就在于databaseconnection和magicalportal都实现了上下文管理器的协议。
静态协议
protocol（静态协议）是python在3.8引入的，通过上面的关于协议的讲解，我们可以发现，协议的坏处就是没有类型提示，所以往往我们可能去调用一个对象不存在的方法，而我们很难在写代码的时候通过mypy或者是ide发现。
from typing import protocol
# 1. 定义静态协议 (契约)
# 注意：我们继承的是 typing.protocol，而不是常规的基类
class messagesender(protocol):
def send(self, message: str) -> bool:
"""只要一个类拥有接受 str 并返回 bool 的 send 方法，
它在静态检查器眼里，就是 messagesender。"""
# 2. 具体实现 (完全不需要继承 messagesender！)
class emailsender:
def send(self, message: str) -> bool:
print(f"📧 发送邮件: {message}")
return true
class smssender:
def send(self, message: str) -> bool:
print(f"📱 发送短信: {message}")
return true
# 3. 一个“假装”能发送，但其实方法名不对的类
class printer:
def print_doc(self, message: str) -> bool:
print(f"🖨️ 打印文档: {message}")
return true
# 4. 客户端调用方
# 在类型注解中指定依赖 protocol
def alert_admin(sender: messagesender, alert_msg: str):
sender.send(alert_msg)
# --- 测试环节 ---
email_sender = emailsender()
sms_sender = smssender()
printer = printer()
# ✅ 这两行在 ide（如 vs code / pycharm）或 mypy 中完全合法
alert_admin(email_sender, "服务器 cpu 超过 90%！")
alert_admin(sms_sender, "数据库连接断开！")
# ❌ 这一行会在代码运行前，直接被 ide 标红报错！
alert_admin(printer, "机房起火了！")@runtime_checkable
在使用 typing.protocol 时，我们获得了极佳的静态类型提示体验（ide 提供智能补全，mypy 静态检查能通过）。但是，由于 protocol 纯粹是为“静态检查”设计的，如果你尝试在代码运行阶段使用 isinstance() 去验证一个对象是否符合静态协议，python 会直接拒绝执行并抛出异常！
from typing import protocol
class burger(protocol):
def eat(self) -> str:
...
class bigmac:
def eat(self) -> str:
return "巨无霸：双层牛肉！"
# 运行这段代码会直接报错：
print(isinstance(bigmac(), burger))为了解决这个问题，让协议既能享受静态类型检查的红利，又能像普通的类一样在运行时使用 isinstance() 进行鸭子类型判断，python 的 typing 模块提供了 @runtime_checkable 装饰器。
它的底层原理，正是我们在上文提到的 __subclasshook__ 黑魔法。加上这个装饰器后，python 会自动在底层拦截 isinstance() 调用，去动态检查对象是否拥有协议中定义的那些方法或属性。
from typing import protocol, runtime_checkable
# 加上装饰器，赋予协议在运行时被 isinstance 检查的能力
@runtime_checkable
class burger(protocol):
def eat(self) -> str:
...
class bigmac:
def eat(self) -> str:
return "巨无霸：双层牛肉！"
class hotdog:
def lick(self) -> str:
return "吃热狗"
mac = bigmac()
dog = hotdog()
# ✅ 运行时完美通过！输出 true，因为 bigmac 拥有 eat 方法
print(f"mac 是 burger 吗？ {isinstance(mac, burger)}")
# ✅ 完美拦截！输出 false，因为 hotdog 没有 eat 方法
print(f"dog 是 burger 吗？ {isinstance(dog, burger)}")使用协议实现依赖倒置
上面我们在讲接口和抽象基类的时候，通过一个汉堡的例子向读者展示怎样实现依赖倒置。这是通过定义抽象基类，让具体实现继承抽象基类burger这个“硬契约”来实现的。而python中的协议其实是更加深层次的抽象，我们无需显式继承，通过实现一套“软契约”来实现。如果说继承是强硬法律的话，协议则更像是一种君子协定。
from typing import protocol
# 1. 定义协议（静态接口/结构化子类型）
class burger(protocol):
def eat(self) -> str:
...
# 2. 具体实现（隐式实现了 burger 协议，完全解耦，无需显式继承）
class bigmac:
def eat(self) -> str:
return "巨无霸：双层牛肉！"
class chickenburger:
def eat(self) -> str:
return "香辣鸡腿堡：脆皮炸鸡！"
# 3. 客户端
class human:
# 【面向协议编程/静态鸭子类型】
# 只要传入的对象拥有和 burger 协议定义一致的 eat 方法，就能通过静态类型检查
def eat_lunch(self, food: burger) -> none:
print(f"人类正在吃: {food.eat()}")
# --- 代码执行 ---
person = human()
person.eat_lunch(bigmac())
person.eat_lunch(chickenburger())通过上面的代码，我们可以看到，我们实现的这套“软契约”其实就是目标对象有没有eat这个方法，有我就认为你是汉堡。为什么说这是更加抽象的方式，因为我们在解耦了汉堡的具体实现与人类的耦合的同时，还无需去显式继承任何基类。
显式继承 (abc)：不仅要求类具备某些方法，还强制要求类在“族谱”上属于某个基类（强耦合的
is-a关系）。协议 (protocol)：完全不在乎对象是从哪里来的、继承自谁，只关心它能不能做这件事（
can-do关系）。实现类根本不需要知道协议的存在，也不需要导入协议所在的模块，这就实现了真正的业务逻辑与接口定义的彻底解耦。
协议黑魔法
现在回到我们开头那个迭代器协议的例子，python是如何“偷偷”实现这个协议的
其实秘密就在于__subclasshook__这个魔法方法，
当我们调用 isinstance(obj, someabc) 时，python 内部的逻辑流如下：
显式继承，检查
obj的类是否继承自someabc。虚拟子类注册，检查
obj的类是否通过someabc.register()注册过。关键点：调用
someabc.__subclasshook__(cls)。如果这个方法返回true，那么即使前两条都不满足，isinstance也会返回true。
所以iterable协议就是通过定义__subclasshook__这个方法，这个方法会去检查__dict__里面会不会存在__iter__这个键，如果存在就返回true。
本文向读者讲解了如何面向接口编程，不去依赖具体的实现，实现依赖倒置。讲解了两种方式，强契约：基类继承，软契约：协议。
总结
到此这篇关于python中的接口、抽象基类和协议的文章就介绍到这了,更多相关python接口、抽象基类和协议内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论