Apple类的协议接口拆分及委托组合使用决策规则咨询

嘿，很高兴你能深挖这些苹果框架设计的细节——这些问题其实触及了iOS/macOS生态里设计模式的核心逻辑，我结合自己的开发经验和对官方框架的理解来聊聊：

一、苹果如何决定类中哪些部分拆分到协议接口？ #

苹果的框架设计一直遵循高内聚、低耦合的原则，拆分协议的判断逻辑大概有这几个方向：

• 分离“稳定核心”与“可变定制”：类本身负责框架的核心、不可变的基础功能——比如UITableView的滚动机制、单元格复用池管理，这些是苹果已经优化好的通用逻辑，不会让开发者修改。而协议则抽离那些需要开发者根据业务定制的部分，比如单元格内容渲染、行高计算、点击事件响应，这些属于业务相关的可变逻辑。
• 践行单一职责原则：如果某个功能模块是“外部响应型”或者“可选扩展型”，就会被放进协议。比如NSSpeechSynthesizer的委托协议里，所有方法都是语音合成过程中的状态回调（开始、结束、出错），这些事件的处理逻辑属于外部业务需求，和合成核心功能（播放、暂停语音）无关，拆分到协议能让主类和回调逻辑各司其职。
• 实现解耦与复用：协议可以让不同的类都能适配同一个框架组件。比如UITableViewDataSource，不管你是从本地Core Data取数据，还是从网络请求拉数据，只要实现这个协议的方法，就能给表格提供数据。这就把表格的展示逻辑和数据来源彻底解耦，复用性拉满。
• 避免类臃肿：如果把所有可定制逻辑都塞进主类，会导致类的职责混乱、代码量爆炸。拆分到协议后，主类保持简洁聚焦，协议也更专注于特定场景的行为集合。

二、苹果使用委托组合的判断标准是什么？ #

委托模式是苹果框架里最常用的设计模式之一，他们选择用委托而非其他方案（比如子类化、闭包）的判断标准大概是这些：

• 需要“反向回调外部逻辑”时：当框架类在某个事件触发后，不知道应该执行什么业务逻辑（比如UITableView用户点击了单元格、NSSpeechSynthesizer语音播放完成），这时候就需要委托来把逻辑交还给开发者。框架只负责通知“发生了什么”，开发者负责决定“要做什么”。
• 替代子类化的更安全方案：苹果很多核心框架不推荐直接子类化（比如UITableView、UIViewController的随意子类化容易踩坑），因为子类化可能破坏框架内部的私有逻辑。而委托是组合模式，开发者只需要实现协议方法，不需要修改框架类本身，既安全又灵活。比如你不用继承UITableView来改单元格样式，只需要实现UITableViewDelegate的对应方法就行。
• 处理“可选逻辑”时：委托协议里的方法很多是@optional标记的，这意味着开发者只需要实现自己关心的部分。比如NSSpeechSynthesizerDelegate里，你可能只需要处理播放完成的回调，不需要关心每个单词的播放状态，这种可选性用委托来实现非常合适。
• 平衡框架的封闭性与扩展性：苹果希望框架的核心逻辑是封闭的（保证稳定性和性能），但又要支持开发者的定制需求。委托正好完美平衡这一点——核心逻辑在框架类里，扩展逻辑通过协议开放给开发者，既不让框架被随意修改，又给了足够的定制空间。

内容的提问来源于stack exchange，提问作者Laurence Wingo