iOS进阶 - 组件化设计探究

组件化架构的设计需要解决三个主要问题：

  • 模块粒度如何划分
  • 如何分层
  • 多团队如何协作

模块粒度如何划分

模块粒度划分需遵循五个原则：

  1. 单一功能原则：对象功能要单一，不要在一个对象里添加很多功能
  2. 开闭原则：扩展是开放的，修改是封闭的
  3. 里式替换原则：子类对象时可以替代基类对象的
  4. 接口隔离原则：接口的用途要单一，不要在一个接口上根据不同入参实现多个功能
  5. 依赖反转原则：方法应该依赖抽象，不要依赖实例。iOS 开发就是高层业务方法依赖于协议。

同时，遵守这五个原则是开发出容易维护和扩展的架构的基础

组件是可组装的、独立的业务单元，具有高内聚，低耦合的特性，是一种比较适中的粒度。iOS组件，应该是包含UI控件、相关多个小功能的合集，是一种粒度适中的模块。

如何分层

对于组件间分层，对多不能超过三层。

  1. 底层可以是业务无关的基础组件，比如网络和存储等
  2. 中间层一般是通用的业务组件，比如账号、埋点、支付、购物车等
  3. 最上层是迭代的业务组件，更新频率最高

这样三层结构设计有利于多个团队分别维护开发。

多团队如何协作

首先需要有一个专门的基建团队，负责业务无关的基础组件功能和业务相关通用业务组件的开发
然后每个业务需要有一个专门的团队来负责开发，业务可以按照功能耦合度来划分，耦合度高的业务可以划分为单独的业务团队。
基建团队人员应该是流动的，从业务团队里来，再回到业务团队中去，业务团队和基建团队的边界不应该非常明显。

组件化设计的两种主要方案

协议式 和 中间者 两种架构

协议式架构主要采用的是协议式编程的思路：在编译层面使用协议定义规范，实现可在不同地方，从而达到分布管理和维护组件的目的。
缺点是：

  1. 由于协议式编程缺少统一调度层，导致难于集中管理
  2. 协议式编程接口定义模式过于规范，从而使得架构的灵活性不够高

中间者模式，采用中间者统一管理的方式来控制App的整个生命周期中组件间的调用关系。
拆分的组件都依赖于中间者，但是组件之间不存在相互依赖的关系了。由于其他组件都会依赖于这个中间者，相互间的通信都会通过中间者统一调度，所以组件间的通信也就更容易管理了。
其中比较好的中间者路由是 CTMediator

极客时间-iOS开发高手课 学习笔记