iOS上使用什么devise模式而不是MVC？
我需要了解除MVC以外的iPhone开发中使用的devise模式。
请使用代码片段回答任何示例说明或示例。
谢谢。
抽象工厂
抽象工厂模式提供了一个接口，用于创build相关或依赖对象的族，而不指定具体的类。 客户与从工厂获得的具体物品的任何具体细节分离。
适配器
适配器devise模式将类的接口转换为客户期望的另一个接口。 适配器让类能够协同工作，否则，因为不兼容的接口。 它将客户从目标对象的类中分离出来。
责任链
责任链devise模式通过给予多个对象一个机会来处理请求，从而将请求的发送者与其接收者分离。 该模式将接收对象链接在一起，并沿着链传递请求，直到对象处理它为止。 链中的每个对象处理请求或将其传递给链中的下一个对象。
命令
命令devise模式将请求作为对象进行封装，从而使您可以使用不同请求参数化客户端，排队或logging请求，并支持可撤销操作。 请求对象将特定接收者上的一个或多个动作绑定在一起。 命令模式将发出请求的对象与接收和执行该请求的对象分开。
综合
复合devise模式将相关对象组合成树结构来表示部分 – 整体层次结构。 该模式可以让客户统一处理个别对象和对象组合。 Composite模式是Model-View-Controller聚合模式的一部分。
装饰
装饰devise模式dynamic地将额外的责任附加到对象上。 装饰器为扩展function提供了子类化的灵活替代scheme。 与子类化一样，修饰器模式的适应性允许您在不修改现有代码的情况下合并新的行为。 装饰器包装了它们扩展行为的类的一个对象。 它们实现与它们所包装的对象相同的接口，并在将任务委托给包装对象之前或之后添加它们自己的行为。 Decorator模式expression了这样的devise原则：类应该是可以打开的，但是可以修改。
正面
Facadedevise模式为子系统中的一组接口提供统一的接口。 该模式定义了一个更高层次的接口，通过降低复杂度并隐藏子系统之间的通信和依赖关系，使子系统更易于使用。
迭代器
迭代器devise模式提供了一种方法来访问聚合对象（即集合）的元素，而不会暴露其基础表示。 迭代器模式将访问和遍历集合元素的责任从集合本身传递给迭代器对象。 迭代器定义了一个访问集合元素的接口并跟踪当前元素。 不同的迭代器可以执行不同的遍历策略。
中间人
介体devise模式定义了一个封装了一组对象如何交互的对象。 中介者通过保持对象明确地相互引用来促进松耦合，并且可以让你独立地改变他们的交互。 这些对象因此可以保持更多的可重用性。 这个模式中的“中介对象”集中了系统中对象之间复杂的通信和控制逻辑，这些对象告诉中介对象何时其状态发生变化，并响应中介对象的请求。
纪念
Memento模式捕获和外部化对象的内部状态 – 不违反封装 – 以便稍后可以将对象恢复到此状态。 Memento模式保持该对象外部的关键对象的重要状态，以保持内聚。
观察
观察者devise模式定义了对象之间的一对多依赖关系，以便当一个对象改变状态时，所有的依赖对象都会被自动通知和更新。 观察者模式本质上是一个发布 – 订阅模式，在这个模式中主体和观察者是松散耦合的。 通信可以发生在观察对象和观察对象之间，而不需要了解其他对象。
代理
代理devise模式为另一个对象提供代理或占位符，以控制对其他对象的访问。 您可以使用此模式创build一个代表或代理对象，用于控制对另一个对象的访问，这可能是远程的，创build成本昂贵或需要进行保护。 这种模式在结构上类似于装饰者模式，但它有不同的用途; 装饰者将行为添加到对象，而代理控制对象的访问。
接待员
接待员devise模式解决了将应用程序的一个执行上下文中发生的事件redirect到另一个执行上下文以进行处理的一般问题。 这是一个混合模式。 虽然它没有出现在“四人帮”一书中，但它结合了该书中描述的命令，备忘录和代理devise模式的元素。 这也是蹦床模式的一个变种（这也没有出现在书中）。 在这种模式中，蹦床对象首先接收事件，所谓的蹦床对象因为它立即反弹或redirect事件到目标对象进行处理。
独生子
Singletondevise模式确保一个类只有一个实例，并提供一个全局的访问点。 该类跟踪其唯一实例，并确保不能创build其他实例。 单一类适用于单个对象提供对全局资源的访问的情况。
模板方法
模板方法devise模式在操作中定义algorithm的框架，将一些步骤推迟到子类。 模板方法模式允许子类重新定义algorithm的某些步骤而不改变algorithm的结构。
来源： cocoadevise模式 。
在现实世界的应用程序中，代码库会随着时间的推移而变得复杂，最终会产生大量的视图控制器，这些控制器很难testing和维护 解决scheme是使用MVVM ，这是MVC自身的更好的select。
在您的应用程序中使用与您的业务逻辑相关的MVVMdevise模式，您将在项目中显示一些内容。 因为你的视图并不需要更多的逻辑来显示它的内容，所以你可以使用MVC，但是如果你必须制作一些业务逻辑来显示这些内容，在这种情况下，最好的做法是把这个逻辑分离到另一个层次，所以MVVM在这种情况下会更好，MVVM中的ViewModel将包含这个逻辑。
在我看来，由于这些原因，MVVM在关卡devise上比MVC要好
- MVVM与您现有的MVC架构兼容。
- MVVM使您的应用程序更易于testing。
- MVVM最适合使用绑定机制。
MVVM如何与MVC兼容
- MVC>模型，视图，控制器
- MVVM> Model，View，ViewModel> Model，（ViewController），ViewModel
