如何制定好的 项目架构 分析

Question

MVC 是很好的面向对象编程范式，非常适合个人开发和小团队开发。

大型项目架构

模块粒度应该怎么划分

• 模块划分必须遵循一定的原则，划分规则要规范、清晰。
• 原则
  • 单一功能原则：对象功能要单一，不要在一个对象里添加很多功能
  • 封闭原则：扩展是开放的，修改是封闭的
  • 里氏替换原则：子类对象是可以替代基类对象的
  • 接口隔离原则：接口的用途要单一，不要在一个接口上根据不同参数实现多个功能
  • 依赖反转原则：方法要依赖抽象，不要依赖实例。iOS开发就是高层业务方法依赖于协议。
• 要选择合适的粒度

组件可以认为是可组装的，独立的业务单元，具有高内聚、低耦合的特性，是一种比较适中的粒度。

iOS组件，应该是包含UI控件，相关多个小功能的合集

组件的层级不要超过三层，依次为基础、功能、业务组件。能够公用的东西做成组件。

项目架构

组件化是解决项目大、人员多的一种很好的手段，这是公认的。组件间关系协调却没有固定的标准，协调的优劣，成为了衡量架构优劣的一个标准。所以在实践中，一般分为了协议式和中间者两种架构模式。

协议式架构

主要采用的是协议式编程的思路：在编译层面使用协议定义规范，实现可在不同地方，从而达到分布管理和维护组件的目的。这种方式也遵循了依赖反转原则，是一种很好的面向对象编程的实践。

缺点：

• 由于协议式编程缺少统一调度层，导致难于集中管理，特别是项目规模变大、团队变多的情况下，架构管控就会显的越来越重要。
• 协议式编程接口定义模式过于规范，从而使得架构的灵活性不够高。当需要引入一个新的设计模式来开发时，我们就会发现很难融入到当前的架构中，缺乏架构的统一性。

由于简单易用扔被很多公司使用。

中间者架构

它采用中间者统一管理的方式，来控制整个App生命周期中组件间的调用关系。 iOS对组件接口的设计也需要保持一致性，方便中间者统一调用。

拆分的组件会依赖中间者，但组件之间就不存在相互依赖的关系了。由于其他组件都会依赖这个中间者，相互间的通信都会通过中间者统一调度，所以组件间的通信也就更容易管理了。在中间者上也能轻松添加新的设计模式，从而使架构更容易扩展。

考虑架构设计时，更多的还是需要在功能逻辑和组件划分上做到同层级解耦合，上下层依赖清晰，这样的结构才能使得上层组件易插拔，下层组件更稳定。而中间者架构模式更容易维护这种结构，中间者的易管控和易扩展性，也使得整体架构能够长期保持稳健与活力。