谈设计模式之前不得不提一下编程中的六大设计原则
一、六大设计原则 ：SOLID
1、单一职责原则
通俗地讲就是一个类只负责一件事。
2、开闭原则
对修改关闭，对扩展开放。
3、接口隔离原则
使用多个专门的协议，而不是一个庞大臃肿的协议。
4、依赖倒置原则
抽象不应该依赖于具体实现，具体实现可以依赖于抽象。
5、里式替换原则
父类可以被子类无缝替换，且原有的功能不受影响。
6、迪米特法则
一个对象应当对其他对象尽可能少地了解，实现高内聚、低耦合。
二、iOS中设计模式的演变
1、MVC
›
全名：Model-View-ViewController
MVC是基础，从设计之初就将模型(Model) 、视图(View)、控制器(Controller)进行了大致的划分，结构清晰，后续设计模式的演变都是围绕着MVC，根据不同的业务场景进行优化的。
形式上的划分：
Model: 负责获取数据；存储数据；
View: 负责数据的展示；接受事件；
Controller: 负责解析数据；业务逻辑处理；创建并更新View
实际开发中：
Model：仅仅是一个数据模型；
View：展示数据；接受并处理事件；
Controller：获取数据；存储数据；解析数据；创建并更新View；处理业务逻辑；处理view的事件；
那么争议的问题来了：
备注：以下说的数据模型指的是
实际开发中到底还是不是MVC设计模式 ？
答：Model、View、Controller 在逻辑上的概念是存在的，只是各自的职责划分不明确。
Model并没有起到管理数据的作用？
答：为了方便使用数据，Model作为了一个数据模型，通过类的属性的方式来映射数据对象；如果Model要获取数据，那么就需要提供数据获取接口；如果要存储数据，就要定义一个字典或者数组作为属性，但它本身又是数据模型，那么就会出现定义的存储属性和Model的循环嵌套。( 有一个办法就是模型不用来映射数据对象，也就是说不定义多个属性用来记录具体的数据名称，仅提供一个存储数据的属性和一个获取数据的接口，当需要使用数据的时候通过数组和字典的形式访问。)
为什么实际开发中没有严格按照MVC的设计模式来做？
答：如果是简单的View，没有必要非得定义一个View类来展示数据；View如果不引用Model，那么就需要暴露出view的subviews或者是与数据模型一样的属性，这样就在Model和View中重复定义了相同名称的属性；数据存储在Controller中使用更方便，
2、MVP
全名： Model-View/ViewController-Presenter
使用Presenter，将Controller中的View剔除，实现View和Model的隔离。
各自的职责：
View负责界面展示和布局管理，向Presenter暴露视图更新和数据获取的接口Presenter负责接收来自View的事件，通过View提供的接口更新视图，并管理ModelModel和MVC中的一样，提供数据模型
3、MVVM
全名:
Model-View-ViewModel
MVVM 是在 MVC 的基础上将业务逻辑抽离到ViewModel层。
各自的职责：
Model提供数据模型，请求下来的原始数据View负责视图的展示，由ViewController控制ViewModel处理业务逻辑，将数据转化为View可以直接使用的数据
4、VIPER
VIPER的全称， View-Interactor-Presenter-Entity-Router。
各自职责：
View：负责视图的组合、布局、更新；
Interactor：处理业务逻辑，向Presenter提供现有的业务用例；维护Entity；处理业务事件，通知Presenter。
Presenter：处理view的事件；向Interactor请求调用业务逻辑，提供view中的数据；通知View进行更新操作；通过Router跳转到其他View。
Entity：和Model一样的数据模型。
Router：提供View之前的跳转功能，减少模块之前的耦合。
