iOS开发架构

一、原件架构的原则

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

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的介绍