一、核心原则 协议只抽象核心行为 避免把大量工具方法直接加到协议中 核心方法 → 多态点 可复用辅助方法 → 放到 protocol extension 或独立协议 用扩展（extension）提供默

一、核心原理 协议 = 能力契约 模块 A 只依赖协议，而不依赖具体类型 B 模块之间只约定“能做什么”，不关心“怎么做” 依赖注入（Dependency Injection, DI） 在对象初始化或

一、核心原理 协议本身不影响性能 协议声明仅定义行为契约 → 无开销 默认实现（protocol extension）默认静态派发 静态派发零开销 → 高性能 协议类型调用 (existential)

一、核心原理 1️⃣ 协议 = “行为契约” 协议只关心能力（what can be done），而不关心具体实现（how it’s done） 当模块 A 依赖模块 B 时，如果模块 A 只依赖协议

一、典型 OOP MVC（面向对象） 特点： User / UserView / UserController 都是 class Controller tightly coupled User 和 U

一、核心原则 二、典型推荐 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