一 iOS MVC、MVVM、MVP
1 MVC
MVC是80年代出现的一种软件设计模式，是模型（model），视图（view）和控制（Controller）的缩写。
其中Model的主要功能包括业务逻辑的处理以及数据的访问，这是应用程序的主体部分。
View的主要功能是用来跟用户进行交互，实现数据的收集和展示，视图是用户看到和直接操作的的界面，它只接受用户的操作。
Controller的主要功能用来在视图和模型之间建立联系并控制数据的走向，控制器本身不输出任何内容和对数据做任何处理。
一个简单的计算器，它除了我们一贯看到的输入输出界面，其实它的内部还有负责运算的模块和负责控制的部件
Controller根据用户在View上的操作，将输入的数字传给Model，model保存数字并根据要求进行加减乘除，进行数据分析，再将得到的结果传给Controllr，由Controller把结果交给View，View把结果显示出来。
缺点:
愈发笨重的 Controller;
太过于轻量级的 Model：
遗失的网络逻辑;
较差的可测试性;
2 MVVM
从字面意思来理解，MVVM 即 Model View ViewModel（模型 视图 视图模型）。MVC 是一个用来组织代码的权威范式，也是构建 iOS App 的标准模式。Apple 甚至是这么说的。在 MVC 下，所有的对象被归类为一个 model，一个 view，或一个 controller。Model 持有数据，View 显示与用户交互的界面，而 View Controller 调解 Model 和 View 之间的交互。然而，随着模块的迭代我们越来越发现 MVC 自身存在着很多不足。因此，MVVM 从其他应用而出，在 iOS 中从此我们完全将业务逻辑加以区分并使用这套思想。在 MVVM 中他的设计思路和 MVC 很像。它正式规范了视图和控制器紧耦合的性质，并引入新的组件 ViewModel。此外，它还有像监管版本的 MVP 那样的绑定功能，但这个绑定不是在 View 和 Model 之间而是在 View 和 ViewModel 之间。
1）MVVM 模式下的三个特性的分析：
任务均摊 -- MVVM 的 View 要比 MVP 中的 View 承担的责任多。因为前者通过 ViewModel 的设置绑定来更新状态，而后者只监听 Presenter 的事件但并不会对自己有什么更新。
可测试性 -- ViewModel 不知道关于 View 的任何事情，这允许我们可以轻易的测试 ViewModel。同时 View 也可以被测试，但是由于属于 UIKit 的范畴，对他们的测试通常会被忽略。
易用性 -- 在实际开发中必须把 View 中的事件指向 Presenter 并且手动的来更新 View，如果使用绑定的话，MVVM 代码量将会小的多。
作者：9岁就很6
链接：https://www.jianshu.com/p/d39a5eee48d7
来源：
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
3 MVP
从字面意思来理解，MVP即Model View Presenter（模型 视图 协调器），MVP实现了Cocoa的MVC的愿景。MVP的协调器Presenter并没有对ViewController的声明周期做任何改变，因此View可以很容易的被模拟出来。在Presenter中根本没有和布局有关的代码，但是它却负责更新View的数据和状态。
MVP 是第一个如何协调整合三个实际上分离的层次的架构模式，既然我们不希望 View 涉及到 Model，那么在显示的 View Controller（其实就是 View）中处理这种协调的逻辑就是不正确的，因此我们需要在其他地方来做这些事情。例如，我们可以做基于整个 App 范围内的路由服务，由它来负责执行协调任务，以及 View 到 View 的展示。这个出现并且必须处理的问题不仅仅是在 MVP 模式中，同时也存在于以下集中方案中。
MVC和MVP的区别就是，在MVP中M和V没有直接通信。
1）MVP模式下的三个特性的分析：
任务均摊 -- 我们将最主要的任务划分到 Presenter 和 Model，而 View 的功能较少；
可测试性 -- 非常好，由于一个功能简单的 View 层，所以测试大多数业务逻辑也变得简单；
易用性 -- 代码量比 MVC 模式的大，但同时 MVP 的概念却非常清晰。
参考：iOS MVC、MVVM、MVP详解 -
工厂模式
简单工厂模式VS. 工厂模式
简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断， 根据客户端的选择条件动态实例化相关的类， 对于客户端来说，去除了具体产品的依赖
工厂方法模式是现实， 客户端需要决定实例化哪一个工厂来实现运算类，选在判断的问题还是存在的， 也就是说， 工厂方法吧简单的工厂的内部逻辑判断移到了客户端代码来进行， 想要加功能， 搬来是修稿工厂类的， 而现在修改的是客户端
工厂模式 相比简单工厂模式 更具有低耦合，可扩展性强。工厂模式保持了简单工厂模式的有点，并且克服了它的缺点， 但工厂模式的缺点是鱿鱼每增加一个产品， 就需要增加一个产品工厂的类， 总价了额外的开发量
为什么使用工厂模式?
在程序开发中,有时候我们不得不根据不同的场景,去创建不同的实体类,利用此种模式,我们可以充分的规划我们的代码,使得项目的层级结构更加清晰,在什么样的场景下,使用什么样的实体
注意事项：作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。(简单来说:不要刻意的为了使用工厂模式,而去使用工厂模式开发,使用工厂模式,仅仅是为了让代码逻辑根据清晰,如果完全可以 alloc 的事情,偏偏写了几个类来实现,那么这样做是得不偿失的)
工厂管理类 ：管理创建
父类： BaseCell
子类1：根据不同需求去实现逻辑代码
子类2：
iOS 工厂模式 -
iOS开发之设计模式 - 工厂模式 -