Swift

一、最常见的 Swift 性能瓶颈层面 1️⃣ 值类型（struct / enum）的拷贝与 Copy-on-Write 常见问题 大 struct 在频繁传参、返回 Array / Dictiona

一、常见挑战与原因 挑战 原因 协议数量膨胀（协议爆炸） 每个小能力都单独抽象 → 模块复杂度增加 默认实现静态派发导致多态问题 protocol extension 默认静态派发 → 协议类型调用行

一、核心原理 协议 = 能力契约 抽象行为而非具体类型 模块只依赖协议 → 低耦合 协议扩展 = 默认实现 / 模板方法 提供通用逻辑 conforming 类型可覆盖 → 保持灵活性 类型组合 +

一、核心原理 协议抽象能力 每个流水线节点可以抽象成一个能力协议（例如 Processable 或 AsyncStep） 模块间只依赖协议 → 解耦 协议扩展提供默认实现 可提供模板方法、通用逻辑、错

一、核心原理 协议（Protocol） 描述业务能力或契约 → 不关心具体类型 模块间只依赖协议，降低耦合 泛型（Generic） 在编译期绑定类型 → 静态派发，高性能 支持值类型 + class

一、核心思想 POP 的关键理念是： 协议 = 能力契约 每个功能单元对应一个协议，描述它能做什么 协议扩展 = 默认实现 提供通用行为模板 类型可以选择覆盖 类型组合协议 = 功能组合 struct

一、协议爆炸的根源 每增加一个小功能就创建一个协议 结果：几十、上百个小协议 → 难以追踪 协议职责不清 一个协议承载多个能力 → 后续扩展难以组合 缺乏层次化 / 模块化 协议散落在全局 → 难以归

一、核心原则 协议只抽象核心行为 避免把大量工具方法直接加到协议中 核心方法 → 多态点 可复用辅助方法 → 放到 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） ：调用方法时