怎么设计一个能够支持大型iOS工程的架构
iOS应该遵循的五个原则(SOLID):
单一功能原则: 对象功能要单一, 不要在一个对象里添加很多功能
开闭原则: 扩展是开放的, 修改是封闭的
里氏替换原则: 子类对象是可以替代基类对象
接口隔离原则: 接口的用途要单一, 不要在一个接口上根据不同入参实现多个功能
依赖反转原则: 方法应该依赖抽象, 不要依赖实例. iOS开发就是高层业务方法依赖于协议
遵守这五个原则是开发出容易维护和扩展的架构的基础
大型项目的模块粒度过大过小都不合适, 组件可以认为是可组装的、独立的业务单元, 具有高内聚, 低耦合的特性, 是一种比较适中的粒度.iOS组件, 应该是包含UI控件、相关多个小功能的合集, 是一种粒度适中的模块.
采用组件, 对于代码逻辑和模块间的通信方式的改动不大, 完成老代码切换也相对容易. 我们可以先按照物理划分, 将多个相同功能的类移动到同一个文件夹下, 然后做成CocoaPods的包进行管理
组件间的层级关系设置
底层可以是与业务无关的基础组件, 比如网络和存储
中间层一般是通用的业务组件, 比如账号、埋点、支付、购物车等
最上层是迭代业务组件, 更新频率最高
三层结构, 有利于多个团队分别开发维护.
协议式和中间者两种架构
协议式架构设计主要采用的是协议式编程的思路: 在编译层面使用协议定义规范, 实现可在不同地方, 从而达到分布管理和维护组件的目的.这种方式也遵守了依赖反转原则, 是一种很好的面相对象编程的实践
缺点也明显:
- 由于协议式编程缺少统一调度层, 导致难于集中管理
- 协议式编程接口定义模式过于规范, 从而使得架构的灵活性不够高, 当需要引入一个新的设计模式开发时, 我们就会发现很难融入到当前架构中, 缺乏架构统一性
另一种中间者架构, 采用中间者统一管理, 来控制App的整个生命周期中组件间的调用关系, 同时, iOS对组件接口的设计也需要保持一致性, 方便中间者统一调用
拆分的组件都会依赖于中间者, 但是组件之间就不存在相互依赖的关系了, 由于其他组件都会依赖于这个中间者, 相互间的通信都会通过中间者统一调度, 所以组件间的通信也就更容易管理了
