Python 鸭子类型与依赖注入

如果一个对象具有某些方法或属性，就可视为符合某种类型，而无需显式声明类型，这就是“鸭子类型”。鸭子类型强调对象的行为，而非其所属的类。但灵活性也带来隐患：没有接口约束，容易出错，IDE无法提示。别担心！Python 提供了优雅的解决方案：用 `typing.Protocol` 显式定义“鸭子契约”，再结合依赖注入（Dependency Injection），让代码既灵活又安全可维护。一、鸭子类型：Python 的默认哲学**不靠继承或接口强制，而靠“有没有这个方法”来判断对象是否可用**。 🦆 经典示例```pythonclass Duck:    def quack(self):        print("Quack!")class Robot:    def quack(self):        print("Beep... Quack!")def make_it_quack(obj):    obj.quack()  # 不管你是鸭子还是机器人，能叫就行！make_it_quack(Duck())   # ✅ Quack!make_it_quack(Robot())  # ✅ Beep... Quack!

✅ 优点：无需继承，天然多态，代码简洁。❌ 缺点：

• • 没有显式契约，别人看不懂“到底需要什么方法”；
• • IDE 无法自动补全；
• • 静态检查工具（如 mypy）会报错；
• • 方法名拼错？运行时才崩溃！

于是，我们需要一个“看得见的鸭子”。

二、用 typing.Protocol 给鸭子贴上“行为标签”

从 Python 3.8 起，标准库引入了 Protocol，允许定义结构化接口——只要实现了指定方法，就视为该协议的实现者，无需继承！

✨ 定义一个“会叫”的协议

from typing import ProtocolclassQuackable(Protocol):defquack(self) -> None: ...classDuck:defquack(self) -> None:print("Quack!")classCat:defmeow(self) -> None:print("Meow!")defmake_it_quack(animal: Quackable) -> None:    animal.quack()make_it_quack(Duck())  # ✅ 正常运行# make_it_quack(Cat()) # ❌ mypy 会报错！Cat 没有 quack 方法

🔍 注：Protocol仅用于类型检查，不影响运行时行为。

🧪 想在运行时检查？用 @runtime_checkable

有时你需要在运行时判断某个对象是否“像鸭子”，比如做日志系统：

from typing import Protocol, runtime_checkable@runtime_checkableclassFlyable(Protocol):deffly(self) -> None: ...classBird:deffly(self) -> None:print("Flying high!")bird = Bird()print(isinstance(bird, Flyable))  # 输出: True

⚠️ 注：@runtime_checkable 只检查方法是否存在，不验证参数签名是否匹配，慎用于高频路径。

三、实战：用 Protocol + 依赖注入构建可扩展系统

下面是一个订单处理场景，使用 Protocol 定义接口 + 依赖注入组装服务的设计。

📦 完整代码与注释

from dataclasses import dataclassfrom typing import Protocol# ─── 定义抽象行为契约 ─────classPaymentProcessor(Protocol):"""支付协议：任何能处理支付的对象都应实现此方法"""defprocess_payment(self, amount: float) -> bool:  ...classShippingProvider(Protocol):"""物流协议：任何能发货的对象都应实现此方法"""defship_order(self, order_id: int) -> str:  ...# ───── 具体实现（无需继承 Protocol）────classStripePaymentService:"""Stripe 支付"""defprocess_payment(self, amount: float) -> bool:print(f"Processing ${amount} via Stripe...")returnTrue# 假设支付成功classFedExShippingService:"""FedEx 物流"""defship_order(self, order_id: int) -> str:        tracking_number = f"FEDEX-{order_id:08d}"print(f"Shipping order： {order_id}, tracking: {tracking_number}")return tracking_number# ─── 核心业务逻辑：依赖抽象，而非具体实现 ───@dataclassclassOrderProcessor:"""    订单处理器：通过构造函数注入依赖    - payment_processor: 符合 PaymentProcessor 协议的对象    - shipping_provider: 符合 ShippingProvider 协议的对象    """    payment_processor: PaymentProcessor    shipping_provider: ShippingProviderdefprocess_order(self, order_id: int, amount: float) -> dict:"""处理完整订单流程：先支付，再发货"""try:# 1. 执行支付ifnotself.payment_processor.process_payment(amount):raise ValueError("Payment failed")# 2. 执行发货            tracking = self.shipping_provider.ship_order(order_id)return {"success": True,"order_id": order_id,"tracking_number": tracking,"message": "Order processed successfully",            }except Exception as e:return {"success": False, "order_id": order_id, "error": str(e)}# ──────────────── 使用依赖注入组装系统 ────────────────defmain():# 创建具体的依赖实例（未来可轻松替换为 PayPal、顺丰等）    payment = StripePaymentService()    shipping = FedExShippingService()# 将依赖注入到业务逻辑中    processor = OrderProcessor(payment, shipping)# 处理一笔订单    result = processor.process_order(order_id=1234, amount=99.99)print(f"Result: {result}")if __name__ == "__main__":    main()

💡 为什么这样设计更优秀？

• • 解耦：OrderProcessor 完全不知道 Stripe 或 FedEx 的存在，只依赖抽象协议；
• • 可替换：想换支付方式？只需实现 PaymentProcessor 协议，传入新实例即可；
• • 可读性强：Protocol 清晰表达了“我需要什么能力”；
• • 兼容静态检查：mypy、PyCharm 能正确推断类型，避免低级错误。

四、总结：最佳实践组合

💡 推荐写法：

1. 1. 用 Protocol 定义接口；
2. 2. 让具体类“自然实现”（无需继承）；
3. 3. 在函数/类中通过参数注入依赖；
4. 4. 未来扩展只需新增实现，不动核心逻辑。

这样，你的代码就同时拥有了 Python 的灵活性 和 工程化的健壮性。

欢迎关注本公众号，获取更多 Python 工程实践、学习技巧！ 🐍✨