一、核心原则 二、典型推荐 OOP 的场景 场景 原因 示例 1️⃣ UIKit / AppKit 或其他框架依赖类层级 框架 API 已经用 class、多态依赖 vtable UIView 子类化

一、问题回顾：多重继承 / 菱形继承 假设在 OOP 中，你想组合行为： 菱形继承问题： D 从 B 和 C 都继承了 A 的方法 → 谁的实现优先？ 语言复杂规则 → 容易出 bug Swift/J

一、核心原因一句话总结 二、继承体系复杂的 OOP 问题 假设你有一个传统 OOP 项目： 常见问题： 深继承树 IconButton 继承 Button → RoundedIconButton 继承

一、核心区别一句话 特性 面向对象设计 (OOP) 面向协议设计 (POP) 核心思想 继承 hierarchies → 类型之间的 is-a 关系 行为契约（protocol） → 类型之间的 ca

一、问题本质 二、典型踩坑示例 分析： foo() 在 A 和 B 的 extension 中都是静态方法 X conform 两个协议 → 没有真正的 override 关系 a.foo() 和 b

一、场景说明：默认实现破坏多态 背景 假设你在写一个 缓存协议 Cache，希望： 提供默认实现 clear() 不同缓存类型（MemoryCache / DiskCache）可以覆盖 1️⃣ 协议

一、核心原则 协议声明 = “多态契约” extension 默认实现 = “默认行为” conforming 类型实现 = “覆盖（override）默认行为” 二、最小示例 输出： ✅ 默认实现被

一、核心原理 静态派发（Static Dispatch） ：调用方法时，编译器在编译期就决定调用哪一个实现。 动态派发（Dynamic Dispatch / Witness Table） ：调用方法时

一、一句话结论（先背下来） 否则，永远不会被覆盖。 二、唯一会被覆盖的情况（正确示例） ✅ 情况：方法在 protocol 中声明 默认实现（extension） 类型提供自己的实现 调用结果（关键）

多协议继承 + protocol extension + 静态派发，如果没想清楚，非常容易写出“看起来合理、运行却诡异”的代码。 我分四步来讲，保证你听完能 一眼识别坑、知道怎么拆： 坑从哪来（本质原

一、场景一：foo() 在 protocol extension 中 1️⃣ 定义协议 + extension 2️⃣ 具体类型“实现”同名方法 3️⃣ 不同调用方式 → 不同结果 ✅ 通过具体类型调

一、一句话总原则（先记住） 这句话几乎能解决 80% 的坑。 二、问题根源回顾（为什么会出问题） 原因只有一个： 三、7 种工程级避免方案（从强到弱） 下面是你在真实项目中 可以直接用的做法。 ✅ 方

一、先给结论（直接命中要害） 所以： 通过具体类型调用 → 编译器知道“你是谁” 通过协议类型调用 → 编译器只能看到“你承诺了什么” 这就导致： 👉 同一个对象，在不同“视角”下，调用的可能是不同实

一、先给一句“人话版”结论 ❌ 只写在 protocol extension 里的方法 👉 静态派发（compile-time） ✅ 在 protocol 中声明、extension 里实现的方法 👉

一、先给结论（工程经验版） 系统边界：协议优先（解耦、替换、测试） 性能核心路径：具体类型 + 泛型 + 静态派发 UI / 业务层：协议适度，避免“协议滥用” 热路径：避免 protocol exi

我会按这个顺序来： 设计目标（为什么要协议 + 泛型） 核心思想（解耦点在哪） 完整示例：网络请求组件 为什么这套设计“真的好用” 可迁移到其他场景的通用模板 一、设计目标（现实问题） 假设你在做一个

🧠 设计动机：解决传统 OOP 的痛点 传统面向对象编程在很多大型工程里会遇到这些问题： 继承树膨胀、僵化 类层级一旦设计，就难以改动。 多重行为只能靠继承链或组合，复杂且难维护。 代码复用靠父类、造

一、共同点：它们在对抗“继承中心主义” 维度 Swift POP Go interface Rust trait 核心抽象 协议（Protocol） 接口（interface） trait 是否支持多

1️⃣ 什么是协议导向编程（POP） 协议导向编程 是 Swift 提出的编程范式，它的核心思想是： 通过协议（protocol）定义接口和行为，而不是依赖类继承。 通过协议扩展（protocol e

Hyperlane is a lightweight and high-performance Rust HTTP server library designed to simplify networ