iOS MVC中的设计模式

MVC是一种用户界面架构模式，同样的MVVM、MVP等都是MVC的变种，iOS平台中用UIViewController来描述页面，内嵌一个UIView作为页面的根视图，Model通常是自定义的用于填充View层的数据

MVC中的三种主要设计模式：观察者模式、组合模式、策略模式
View与Model的关系是基于观察者模式来实现的，即模型变化之后要通知视图状态刷新
View与子View之间是组合关系，即View支持嵌套，组合视图与视图有类似的对象行为
View与Controller的关系是策略模式的一种实现，即View产生的事件由Controller提供一个响应策略

此外MVC中还用到：创建控制器的工厂方法和单例模式，View与Layer之间的代理模式、View与Controller之间的代理模式，滚动视图的装饰模式等。传统的设计模式有23种，分为三类：创建型、结构型、行为型

创建型模式

抽象工厂模式（abstract factory）

意图：
提供一个接口，用来创建一组相关或者相互依赖的对象，而无需指定他们的具体类
适用范围：
提供一个产品类库，显示它们的接口，隐藏具体实现，使系统独立于产品的创建、组合、表示

构造器模式（builder）

意图：
将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示
适用范围：
创建复杂对象的算法独立于对象的组成部分和装配方式

工厂方法模式（factory method）

意图：
定义一个用于创建对象的接口，让子类决定实例化哪一个类，从而将一个类的实例化延迟到其子类
适用范围：
对象创建接口统一化，实例化职责子类化、局部化

原型模式（prototype）

意图：
用原型实例指定创建对象的种类，通过拷贝实例创建新的对象
适用范围：
当一个类的实例只能有几个不同状态组合中的一种时，创建相应数目的原型实例并在使用时直接拷贝他们，类似一种缓存机制，以减少频繁创建对象的开销

单例模式（singleton）

意图：
提供一个类的唯一实例的全局访问接口
适用范围：
当一个类只能有一个实例并且需要一个全局访问点访问时

结构型模式

适配器模式（adapter）

意图：
使不同的接口转换成为客户端希望的统一接口
适用范围：
封装那些已经存在的类，输出统一的接口，实现相同功能的同时隐藏具体实现细节

桥接模式（bridge）

意图：
将抽象部分与实现部分分离，使它们可以独立变化
适用范围：
抽象和具体实现之间没有绑定关系，对实现部分改变不应该影响抽象部分，即客户端不必重新编译

组合模式（composite）

意图：
将对象组合为树形结构以表示“部分 - 整体”的关系，用户对单个对象和组合对象的使用具有一致性
适用范围：
表达部分与整体的关系，同时客户端不用关心组合对象和单个对象的不同点，而是统一使用组合结构中的对象

装饰模式（decorator）

意图：
动态递给一个对象添加额外的职责而无需生成子类
适用范围：
该模式适合处理那些可以撤销的职责，在不影响其他对象的前提下，动态地给类添加职责

门面模式（facade）

意图：
为子系统提供一个统一的更高层次接口，使得子系统更加易用
适用范围：
复杂系统可以拆分为更小粒度的子系统，把他们有层次的组织在一起，封装子系统的协同部分，使整个系统更易用

享元模式（flyweight）

意图：
运用共享技术支持大量细粒度的对象
适用范围：
一个系统使用了大量的对象，造成了大量的存储开销，对象的大多数状态都可以变为外部状态，系统不依赖于对象标识

代理模式（proxy）

意图：
为其他对象提供一种方式以控制这个对象的访问
适用范围：
将一些特性提供给外部对象访问，已在合适的时机控制被代理的对象

行为型模式

责任链模式（chain of responsibility）

意图：
使多个对象都有机会处理请求，解除请求发送者和接收者之间的耦合关系，将这些对象连接成为一条链，沿着链条传递请求，直到有一个对象处理它为止
适用范围：
请求发送者不关心响应者，链条中的那个对象处理该请求运行时自动确定

命令模式（chain of responsibility）

意图：
将一个操作封装成为一个对象，从而可以实现多个操作的排队、记录和撤销等
适用范围：
抽象出待执行的动作以参数化某个对象，支持排列、撤销、记录日志，提供一个公共接口，使得可以用同样的方式调用所有动作

解释器模式（interpreter）

意图：
定义一个语义，并定义一个解释器，该解释器使用该语义来解释语言中的句子
适用范围：
当有一个语言需要解释执行并且可以将语言中的句子表示为一个抽象语法树的时候，可以使用解释器模式，更适用于文法简单，并且效率不是关键问题的场景

迭代器模式（iterator）

意图：
提供一种方法顺序访问一个聚合对象中的各个元素，而又无需暴露对象的内部表示
适用范围：
为遍历不同聚合结构提供一个统一接口，支持对结构的多种遍历

中介者模式（mediator）

意图：
用一个中间对象来封装一系列对象的交互，使得各个对象只依赖这个中间对象，从而实现松散耦合
适用范围：
复杂系统的类之间交错依赖，难以复用，中介者模式就是收敛这种依赖，使各个模块都与之通讯，再由中介者负责中间调度

备忘录模式（memento）

意图：
在不破坏对象封装的前提下，捕获其内部的状态，并将其保存在对象之外，以在需要的时候回复对象原来的状态
适用范围：
需要保存一个对象的时刻状态，以在需要的时候进行恢复，比如文件撤销操作，游戏回档

观察者模式（observer）

意图：

定义一种对象间的依赖关系，当对象状态变更时通知所有依赖于它的对象进行更新
适用范围：
一个对象的改变需要同时改变其他对象，不用关心具体有多少对象需要改变，谁需要谁订阅

状态模式（state）

意图：
允许一个对象在其内部状态改变时改变相应的行为
适用范围：
一个对象有多种行为，运行时根据状态不同会执行不同的行为，即一个操作中有大量的条件分支，并且这些分支依赖于该对象的状态

策略模式（strategy）

意图：
封装一系列算法，它们之间可以相互替换并且独立于使用它们的系统
适用范围：
客户端希望通过统一的接口来调用不同的算法，使之在表达形式一致的同时具备不同的功能，该算法同时封装条件分支和数据处理过程

模板方法模式（template method）

意图：
定义一个操作的算法骨架，而将一些具体的步骤延迟到子类中，使得在不改变算法机构的同时即可改变算法的部分特性
适用范围：
一次性实现算法的不变部分，将可变的部分留给子类来实现，通用部分集合在父类，提高代码复用，同时控制子类扩展范围

访问者模式（visitor）

意图：
定义一个访问者，它可以再不改变类的前提下提供作用于类元素的新操作
适用范围：
定义对象结构的类很少改变，但是经常需要在此结构上定义新的操作

写在最后

以上内容参考计算机科学丛书，设计模式-可复用面向对象软件的基础一书，本文只是留一个坑，后续笔者会根据OC语言的特性，用每一种或多种设计模式创造一些实际项目中可用的轮子~~