iOS 常用设计模式汇总

在软件开发中,无论是那种高级语言中总会伴随着一些最为常用的设计模式,下面针对iOS中,MVC模式、代理模式、观察者模式、单例模式、策略模式、简单工厂模式这六大模式进行汇总分析。

一、MVC模式

MVC是一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑

1.1实例

MVC(Model View Controller)模型(model)-视图(view)-控制器(controller)

1.1.1模型对象

模型对象封装了应用程序的数据,并定义操控和处理该数据的逻辑和运算。例如,模型对象可能是表示游戏中的角色或地址簿中的联系人。用户在视图层中所进行的创建或修改数据的操作,通过控制器对象传达出去,最终会创建或更新模型对象。模型对象更改时(例如通过网络连接接收到新数据),它通知控制器对象,控制器对象更新相应的视图对象。

1.1.2视图对象

视图对象是应用程序中用户可以看见的对象。视图对象知道如何将自己绘制出来,并可能对用户的操作作出响应。视图对象的主要目的,就是显示来自应用程序模型对象的数据,并使该数据可被编辑。尽管如此,在 MVC 应用程序中,视图对象通常与模型对象分离。
在iOS应用程序开发中,所有的控件、窗口等都继承自 UIView,对应MVC中的V。UIView及其子类主要负责UI的实现,而UIView所产生的事件都可以采用委托的方式,交给UIViewController实现。

1.1.3控制器对象

在应用程序的一个或多个视图对象和一个或多个模型对象之间,控制器对象充当媒介。控制器对象因此是同步管道程序,通过它,视图对象了解模型对象的更改,反之亦然。控制器对象还可以为应用程序执行设置和协调任务,并管理其他对象的生命周期。

model_view_controller.png

1.2应用场景

MVC模式是一中非常古老的设计模式,通过数据模型,控制器逻辑,视图展示将应用程序进行逻辑划分。

1.3优势

MVC模式使系统,层次清晰,职责分明,易于维护

1.4敏捷原则

MVC模式对扩展开放-对修改封闭

二、代理模式

代理模式完成委托方交给的任务,委托方有一些任务自己不想完成,但是还需要要实现,则将该任务存放到协议中,由代理完成.但是代理并不会主动的执行任务,需要委托方通知代理。

2.1应用场景

当一个类的某些功能需要由别的类来实现,但是又不确定具体会是哪个类实现。

2.2优势

解耦合

2.3敏捷原则

开放-封闭原则

2.4实例

tableview的 数据源delegate,通过和protocol的配合,完成委托诉求。列表row个数delegate,自定义的delegate。

三、观察者模式

观察者模式本质上是一种发布-订阅模型,用以消除具有不同行为的对象之间的耦合,通过这一模式,不同对象可以协同工作,同时它们也可以被复用于其他地方Observer从Subject订阅通知,ConcreteObserver实现重现ObServer并将其重载其update方法。

3.1应用场景

一般为model层对,controller和view进行的通知方式,不关心谁去接收,只负责发布信息。

3.2优势

解耦合

3.3敏捷原则

接口隔离原则,开放-封闭原则

3.4实例

Notification通知中心,注册通知中心,任何位置可以发送消息,注册观察者的对象可以接收。
kvo,键值对改变通知的观察者,平时基本没用过。

四、单例模式

单例模式可以保证App在程序运行中,一个类只有唯一个实例,从而做到节约内存。
在整个App程序中,这一份资源是共享的。
提供一个固定的实例创建方法。

4.1应用场景

确保程序运行期某个类,只有一份实例,用于进行资源共享控制。

4.2优势

使用简单,延时求值,易于跨模块

4.3敏捷原则

单一职责原则

4.4实例

[UIApplication sharedApplication]。

4.5注意事项

确保使用者只能通过 getInstance方法才能获得,单例类的唯一实例。
java,C++中使其没有公有构造函数,私有化并覆盖其构造函数。
object c中,重写allocWithZone方法,保证即使用户用 alloc方法直接创建单例类的实例,
返回的也只是此单例类的唯一静态变量。

五、策略模式

策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。

5.1应用场景

定义算法族,封装起来,使他们之间可以相互替换。

5.2优势

使算法的变化独立于使用算法的用户

5.3敏捷原则

接口隔离原则;
多用组合,少用继承;
针对接口编程,而非实现。

5.4实例

排序算法,NSArray的sortedArrayUsingSelector;经典的鸭子会叫,会飞案例。

5.5注意事项

1、剥离类中易于变化的行为,通过组合的方式嵌入抽象基类
2、变化的行为抽象基类为,所有可变变化的父类
3、用户类的最终实例,通过注入行为实例的方式,设定易变行为
防止了继承行为方式,导致无关行为污染子类。完成了策略封装和可替换性。

六、简单工厂模式

简单工厂模式中定义一个抽象类,抽象类中声明公共的特征及属性,抽象子类继承自抽象类,去实现具体的操作。工厂类根据外界需求,在工厂类中创建对应的抽象子类实例并传给外界,而对象的创建是由外界决定的。外界只需要知道抽象子类对应的参数即可,而不需要知道抽象子类的创建过程,在外界使用时甚至不用引入抽象子类。

6.1应用场景

工厂方式创建类的实例,多与proxy模式配合,创建可替换代理类。

6.2优势

易于替换,面向抽象编程,application只与抽象工厂和易变类的共性抽象类发生调用关系。

6.3敏捷原则

DIP依赖倒置原则

6.4实例

项目部署环境中依赖多个不同类型的数据库时,需要使用工厂配合proxy完成易用性替换

6.5注意事项

项目初期,软件结构和需求都没有稳定下来时,不建议使用此模式,因为其劣势也很明显,增加了代码的复杂度,增加了调用层次,增加了内存负担。

1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义   就一个类而言,应该仅有一个引起它变化的原因。 定义解读   这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出   假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案   遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。   说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

网罗开发

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值