一、软件架构的原则
软件架构的七大原则如下：
1.开闭原则
2.依赖倒置原则
3.单一职责原则
4.接口隔离原则
5.迪米特法则（最小知道原则）
6.里氏替换原则
7.合成/聚合复用原则
8.图片描述
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中处理，方便单元测试和自动化测试。
我们在实际开发中一定要根据我们的实际情况来选择架构模式，不要一味地追新，适合自己当下业务的架构模式才是好的架构模式，不要画虎不成反类犬。
以上只是个人见解，如有不同见解，还望不吝赐教。
咱们有一个大型“iOS开发同性”交流群：679884541 ！有问题可以在群里一起交流，群里还有群主精心准备的最新面试题合集和进阶学习资料，欢迎你的加入！
