多年来,我参与过许多 Python 项目,从大型企业系统到模块化库,一个持续的挑战是以清晰、可维护和可扩展的方式定义和实施对象的行为,Python 为此提供了两个强大的工具:协议和抽象基类 (ABC)。
虽然两者都有助于定义对象应该做什么,但它们迎合了不同的场景和思维方式,在这篇文章中,我将向你介绍它们是什么、它们如何工作以及我发现它们何时最有用。
如果你曾经使用过 Python 的动态鸭子类型方法,你可能已经体验过依赖对象以某种方式“嘎嘎”的自由(和混乱),协议采用这个想法,并通过类型提示将其形式化。
Python 的 typing 模块 (3.8+) 中引入的协议提供了一种无需显式继承即可定义接口的方法,协议定义了对象必须实现的一组方法或属性才能被视为 “兼容”,协议的特别之处在于它们不关心继承 — 任何具有所需方法或属性的对象都满足协议。
让我们举一个受我使用的财务分析工具启发的示例,系统处理来自 API、数据库和 CSV 文件等各种来源的数据,每个数据源对象都有 and 方法,但它们不共享公共父类,我们需要一种方法来确保这些对象与共享的处理函数一起工作,而无需强制重构。
from typing import Protocolclass DataSource(Protocol): def read(self) -> str: ... def write(self, data: str) -> None: ...class APIClient: def read(self) -> str: return "Data from API" def write(self, data: str) -> None: print(f"Sending data to API: {data}")class CSVHandler: def read(self) -> str: return "Data from CSV" def write(self, data: str) -> None: print(f"Writing to CSV: {data}")def process_data(source: DataSource) -> None: data = source.read() print(f"Processing: {data}") source.write("Processed data")api_client = APIClient()csv_handler = CSVHandler()process_data(api_client) # Works with APIClientprocess_data(csv_handler) # Works with CSVHandler此方法允许函数接受满足协议的任何对象。这就是为什么我认为协议在这种情况下效果很好:
DataSourcereadwriteprocess_dataAPIClientCSVHandler根据我的经验,协议在处理遗留代码或集成第三方库时特别有用,由于它们不需要继承,因此它们可以提供类型安全并强制执行行为,而无需强制你重构现有系统。
在后台,Python 使用元类使协议同时用作类型提示和运行时验证器,当你使用 Python 定义协议时,Python 会创建一个处理结构类型检查的特殊元类,这意味着,如果对象实现了所需的方法和属性,则该对象被视为协议的虚拟子类。
print(issubclass(APIClient, DataSource)) # Trueprint(isinstance(csv_handler, DataSource)) # True既不是 NOR 显式继承自 ,但 Python 的元类机制确保它们符合条件,因为它们实现了 and 方法。APIClientCSVHandlerDataSourcereadwrite
请注意,如果需要在运行时验证协议,则必须使用模块中的装饰器,没有它,检查将不起作用:@runtime_checkabletypingisinstanceissubclass
from typing import runtime_checkable@runtime_checkableclass DataSource(Protocol): def read(self) -> str: ... def write(self, data: str) -> None: ...print(isinstance(api_client, DataSource)) # True这种灵活性使协议在类型检查方面特别强大,同时保持代码的动态性和可扩展性。
协议具有很高的灵活性,但有时你需要更结构化的方法,这就是抽象基类 (ABC) 的用武之地,ABC 是一种工具,通过定义 subclasses 必须实现的严格接口来强制执行一致行为,与协议不同,ABC 需要显式继承,因此当你希望在代码中明确定义层次结构时,它们是更好的选择。
我发现 ABC 在系统的设计阶段特别有用,因为你从头开始构建东西,并希望确保所有子类都遵循一个通用的契约。
假设我们正在构建一个系统,其中每个插件都会生成一个报告并需要特定的配置,在这里,我们可以使用 ABC 来强制执行一个结构,其中所有插件都实现了 method 和 .generate_reportconfigure
from abc import ABC, abstractmethodclass ReportPlugin(ABC): @abstractmethod def generate_report(self, data: dict) -> str: """Generate a report based on the given data.""" pass @abstractmethod def configure(self, settings: dict) -> None: """Configure the plugin with specific settings.""" passclass PDFReportPlugin(ReportPlugin): def generate_report(self, data: dict) -> str: return f"PDF Report for {data['name']}" def configure(self, settings: dict) -> None: print(f"Configuring PDF Plugin with: {settings}")class HTMLReportPlugin(ReportPlugin): def generate_report(self, data: dict) -> str: return f"HTML Report for {data['name']}" def configure(self, settings: dict) -> None: print(f"Configuring HTML Plugin with: {settings}")def run_plugin(plugin: ReportPlugin, data: dict, settings: dict) -> None: plugin.configure(settings) report = plugin.generate_report(data) print(report)pdf_plugin = PDFReportPlugin()run_plugin(pdf_plugin, {"name": "John Doe"}, {"font": "Arial"})html_plugin = HTMLReportPlugin()run_plugin(html_plugin, {"name": "Jane Smith"}, {"color": "blue"})在此示例中:
ReportPlugingenerate_reportconfigurerun_plugin协议和 ABC 之间的选择并不总是非黑即白的,根据我的经验,这通常取决于项目的背景和你的目标,以下是帮助你决定使用哪种方法的一般准则:
根据我的经验,协议和抽象基类不是相互竞争的工具,它们是互补的,我使用协议将类型安全改造到遗留系统中,而无需进行大量重构,另一方面,在从头开始构建系统时,我一直依赖 ABC,其中结构和一致性至关重要。
在决定使用哪个时,请考虑项目的灵活性需求和长期目标,协议提供灵活性和无缝集成,而 ABC 有助于建立结构和一致性,通过了解它们的优势,你可以选择合适的工具来构建强大、可维护的 Python 系统。
长按或扫描下方二维码,免费获取 Python公开课和大佬打包整理的几百G的学习资料,内容包含但不限于Python电子书、教程、项目接单、源码等等 推荐阅读
DBOS:让 Python 工作流持久化,轻松应对中断与重试
不想折腾 Celery?试试这个轻量级 Django 异步任务方案
点击 阅读原文 了解更多