除了MVC之外,iOS上使用了哪些设计模式?

时间:2012-09-15 10:16:12

标签: ios objective-c swift architecture

我需要了解除了MVC之外的iPhone开发中使用的设计模式。

请回复任何示例说明或带有代码段的示例。

感谢。

3 个答案:

答案 0 :(得分:108)

Abstract Factory

抽象工厂模式提供了一个接口,用于创建相关或从属对象的族,而无需指定其具体类。客户端与从工厂获得的具体对象的任何细节分离。

Adapter

适配器设计模式将类的接口转换为客户期望的另一个接口。适配器允许类一起工作,否则由于不兼容的接口。它将客户端与目标对象的类分离。

Chain of Responsibility

责任链设计模式通过为多个对象提供处理请求的机会,将请求的发送者与其接收者分离。该模式将接收对象链接在一起,并沿着链传递请求,直到对象处理它为止。链中的每个对象都处理请求或将其传递给链中的下一个对象。

Command

Command设计模式将请求封装为对象,从而允许您使用不同的请求,队列或日志请求参数化客户端,并支持可撤销操作。请求对象将特定接收器上的一个或多个动作绑定在一起。 Command模式将发出请求的对象与接收和执行该请求的对象分开。

Composite

复合设计模式将相关对象组合成树结构以表示部分整体层次结构。该模式允许客户统一处理单个对象和对象组合。 Composite模式是Model-View-Controller聚合模式的一部分。

Decorator

Decorator设计模式动态地将附加职责附加到对象。装饰器为子类化提供了灵活的替代扩展功能。与子类化一样,修饰器模式的调整允许您在不修改现有代码的情况下合并新行为。装饰器包装类的对象,它们的行为扩展。它们实现与它们包装的对象相同的接口,并在将任务委派给包装对象之前或之后添加它们自己的行为。 Decorator模式表达了这样的设计原则,即类应该对扩展开放,但不能修改。

Facade

Facade设计模式为子系统中的一组接口提供统一接口。该模式定义了一个更高级别的接口,通过降低复杂性和隐藏子系统之间的通信和依赖关系,使子系统更易于使用。

Iterator

Iterator设计模式提供了一种顺序访问聚合对象(即集合)元素的方法,而不会暴露其底层表示。 Iterator模式将访问和遍历集合元素的责任从集合本身转移到迭代器对象。 Iterator定义了一个访问集合元素的接口,并跟踪当前元素。不同的迭代器可以执行不同的遍历策略。

Mediator

Mediator设计模式定义了一个对象,该对象封装了一组对象的交互方式。 Mediator通过使对象明确地相互引用来促进松散耦合,并且它允许您独立地改变它们的交互。因此,这些对象可以保持更多的可重用性。 这种模式中的“中介对象”集中了系统中对象之间的复杂通信和控制逻辑。这些对象在状态发生变化时告诉介体对象,然后响应来自中介对象的请求。

Memento

Memento模式捕获并外化对象的内部状态 - 不违反封装 - 以便稍后可以将对象恢复到此状态。 Memento模式将关键对象的重要状态保持在该对象外部以保持内聚。

Observer

Observer设计模式定义了对象之间的一对多依赖关系,这样当一个对象更改状态时,其所有依赖关系都会自动得到通知和更新。 Observer模式本质上是一个发布 - 订阅模型,主体及其观察者松散耦合。可以在观察对象和被观察对象之间进行通信,而无需了解对方。

Proxy

代理设计模式为另一个对象提供代理或占位符,以便控制对该另一个对象的访问。您可以使用此模式创建一个代表或代理对象,该对象控制对另一个对象的访问,该对象可能是远程的,创建起来很昂贵,或者需要保护。这种模式在结构上类似于装饰器模式,但它有不同的用途; Decorator向对象添加行为,而Proxy控制对对象的访问。

Receptionist

接待员设计模式解决了将在应用程序的一个执行上下文中发生的事件重定向到另一个执行上下文以进行处理的一般问题。这是一种混合模式。虽然它没有出现在“四人帮”一书中,但它结合了该书中描述的Command,Memo和Proxy设计模式的元素。它也是蹦床模式的变体(也没有出现在书中);在这种模式中,事件最初是由蹦床对象接收的,因为它会立即将事件反弹或重定向到目标对象进行处理。

Singleton

Singleton设计模式确保一个类只有一个实例,并提供一个全局访问点。该类跟踪其唯一实例,并确保不能创建其他实例。 Singleton类适用于单个对象提供对全局资源的访问的情况。

Template Method

模板方法设计模式定义操作中算法的骨架,将一些步骤推迟到子类。模板方法模式允许子类重新定义算法的某些步骤而不改变算法的结构。

来源: Cocoa Design Patterns

答案 1 :(得分:2)

在现实世界的应用程序中,代码库随着时间的推移变得复杂,最终会出现大量的视图控制器,这些控制器难以测试和维护。解决方案是使用MVVM,这是自己的MVC的更好替代方案。

答案 2 :(得分:1)

在应用程序中使用MVVM设计模式与您在项目中将要在视图中显示某些内容的业务逻辑相关。 如果您的视图不需要更多逻辑来显示它可以使用MVC的内容 但是如果你必须制作一些业务逻辑来在视图上显示这些内容,在这种情况下的最佳实践是将这个逻辑分离到另一层,这样MVVM在这种情况下会更好,MVVM中的ViewModel将包含这个逻辑。

在我看来,由于这些原因,MVVM在级别设计上优于MVC

  • MVVM与您现有的MVC架构兼容。
  • MVVM使您的应用更具可测性。
  • MVVM最适合使用绑定机制。

MVVM如何与MVC兼容

  • MVC>模型,视图,控制器
  • MVVM>模型,视图,ViewModel>模型,(视图控制器),视图模型