乐趣区

iOS开发架构

jiezi

一、原件架构的原则

软件架构的七大原则如下：

  1. 开闭原则
  2. 依赖倒置原则
  3. 单一职责原则
  4. 接口隔离原则
  5. 迪米特法则（最小知道原则）
  6. 里氏替换原则
  7. 合成 / 聚合复用原则

1. 开闭原则

对扩展开放，对修改关闭。

说的是, 在设计一个模块的时候, 应当使这个模块可以在不被修改的前提下被扩展.
换言之, 应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。

例如：一般 软件功能的升级 就需要符合开闭原则，即不去修改原来的代码，而是去增加新功能。

2. 依赖倒置原则

实现尽量依赖抽象，不依赖具体实现。
该原则有以下三点说明：

  • 1、高层模块不应该依赖于底层模块，两者都应该依赖于抽象。
  • 2、抽象不应该依赖于细节，即具体实现类。
  • 3、细节应该依赖于抽象。

这样带来的好处，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且可以降低修改程序所造成的的风险。

这就是我们通常说的 面向接口编程。

3. 单一职责原则

对于一个类而言，应该仅存在一个可以引起类变化的原因。

这条原则从字面意思来说就是：一个类、接口、方法职责尽量单一。这样我们就能很好的进行解耦，后期的需求变更和维护不会互相受影响，能够降低类的复杂度，提高可读性。

4. 接口隔离原则

客户端不应该依赖它不需要的接口，类之间的依赖关系应该建立在最小的接口上。
这个原则指导我们在设计接口时应当注意以下几点：

  • 1、一个类对另一个类的依赖应该建立在最小的接口之上。
  • 2、建立单一接口，不要建立功能繁多的总接口。
  • 3、尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。

该原则符合 高内聚低耦合 的设计思想，可以使类具有很好的 可读性、可扩展性和可维护性。

5. 迪米特法则（最小知道原则）

一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合。

由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。迪米特法则不希望类之间建立直接的联系。如果有真的需要建立联系的，也希望能通过他的友元类来转达。

迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类，而出现在方法体内部的类不属于朋友类。

6. 里氏替换原则

一个软件实体如果适用一个父类的话，那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。

我们总结一下：子类可以扩展父类的功能，但不能改变父类原有的功能。

  • 1、子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
  • 2、子类中可以增加自己特有的方法。
  • 3、当子类的方法重载父类的方法时，方法的前置条件（即方法的输入 / 入参）要比父类方法的输入参数更宽松。
  • 4、当子类的方法实现父类的方法时（重写 / 重载或实现抽象方法），方法的后置条件（即方法的输出 / 返回值）要比父类更严格或相等。

使用里氏替换原则有以下优点：

  • 1、约束继承泛滥，开闭原则的一种体现。
  • 2、加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低需求变更时引入的风险。

7. 合成 / 聚合复用原则

尽量使用对象组合(has-a)/ 聚合(contanis-a)，而不是继承关系达到软件复用的目的。

换句话说，就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新的对象通过这些对象的委派达到复用已有功能的目的。

该原则可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。

二、MVC 架构


MVC 是 Model-View-Controller 的简写。MVC 主要有三层：

  • Model：数据层，读写数据，保存 App 状态。
  • View：页面层，和用户交互，向用户显示页面，反馈用户行为。
  • ViewController：逻辑层，更新数据，或者页面，处理业务逻辑。

MVC可以帮助你很好的将数据，页面，逻辑的代码分离开来。使得每一层相对独立。这样你就能够将一些可复用的功能抽离出来，化繁为简。只不过，一旦 App 的交互变复杂，你就会发现 ViewController 将变得十分臃肿。大量代码被添加到 控制器 中，使得 控制器 负担过重。

此处特别说明 ：如果只是为了解决 VC 中代码臃肿的短板，把 VC 中的逻辑代码按功能模块使用 分类（category）进行拆分，只保留必要的调用接口能有效的降低 VC 中代码臃肿的问题。

三、MVVM 架构

MVVM是 Model-View-ViewModel 的简写，是由 MVP（Model-View-Presenter）模式与 WPF 结合的应用方式时发展演变过来的一种新型架构框架。

MVVM 层架结果如下：

  • Model：数据层，读写数据，保存 App 状态。
  • View：页面层，提供用户输入行为，并且显示输出状态。
  • ViewModel 逻辑层，它将用户输入行为，转换成输出状态。
  • ViewController：主要负责数据绑定。

这里其实叫 MVVM-C 架构更合适。

ViewModel 是逻辑层，而 控制器 只需要负责数据绑定。如此一来 控制器 的负担就减轻了许多。并且 ViewModel 与控制器 以及 页面 相独立。那么，你就可以跨平台使用它。你也可以很容易地测试它。

MVVM 模式 使用的是 数据绑定 基础架构，这是 MVVM 设计模式的核心，在使用中，利用 双向绑定技术，使得 Model 变化时，ViewModel 会自动更新，而 ViewModel 变化时，View 也会自动变化。ViewModel 包含所有由 UI 特定的接口和属性，并有一个 ViewModel 的视图的绑定属性，当绑定的属性变化时，View 会自动更新视图，所以可以把更新视图的逻辑放到 ViewModel 中，减少了 Controller 的代码，iOS 实现这种绑定可以使用 通知 和 KVO。

ViewModel其实相当于一个黑盒子，接收输入，经过内部业务逻辑处理产出结果。

四、总结

本文主要介绍了 软件架构的七大原则、MVC 架构模式、MVVM 架构模式。

不管我们选择何种架构模式，我们都是朝着代码的 可扩展性 、 可维护性 、 复用性 、 可读性 去的。我们最终的目的都是为了 降低代码的耦合性，方便后续的修改、扩展和维护。

MVVM 模式 与MVC 模式 最大的特点 并不是降低了 VC 中代码的臃肿，而是 MVMM 架构模式把业务逻辑统一到了 VM 中处理，方便单元测试和自动化测试。

我们在实际开发中一定要根据我们的实际情况来选择架构模式，不要一味地追新，适合自己当下业务的架构模式才是好的架构模式，不要画虎不成反类犬。

以上只是个人见解，如有不同见解，还望不吝赐教。

参考引用

软件架构的七大原则
RxSwift 中 MVVM 的介绍

退出移动版