iOS开发中的几种设计模式（OC）

在iOS开发中经常用到的设计模式主要有以下几种：
1.MVC模式
2.单例模式
3.代理模式
4.观察者模式（一般分为：通知和KVO）
5.策略模式
6.工厂模式

一、MVC模式：
应用场景：是一种非常古老的框架级的设计模式，通过数据模型，控制器逻辑，视图展示将应用程序进行逻辑划分。（另外还有很多人用的是MVVM，有兴趣的同学可以自行了解。）
优势：使系统，层次清晰，职责分明，易于维护
原则：对扩展开放-对修改封闭
实例：model-即数据模型，view-视图展示，controller进行UI展现和数据交互的逻辑控制。
Model:
模型保存应用程序的数据，定义了怎么去操作它。在开发过程中，从服务器请求到的数据必须要经过处理才能进行使用的，而处理过程，我们就可以写在model中，这样我们controller中的代码就会变得更加简洁、清晰、有条理。
View:
视图是模型数据的可视化表示以及用户交互的控件；基本上来说，所有的UIView对象以及它的子类都属于视图。在开发过程中，各个控件的创建，布局都可以写在一个封装好的view中，同样可以使controller中的代码变得简洁。
Controller:
控制器是一个协调所有工作的中介者（Mediator，所以MVC模式有时也会称为中介者模式）。它将model和view连接起来，将模型model中的数据在视图中展示出来，同时它们还监听事件和根据需要操作数据。主要负责同用户间的交互。
在理想的状态下，视图应该和模型完全的分离（但是不容易做到）。如果视图不依赖某个实际的模型，那么视图就可以被复用来展示不同模型的数据。（比如一个APP的多个界面，上半部分是不同的界面布局，但是下半部分的视图都是一个tableView且cell布局相同，只有内容不同，这个时候我们就可以复用这个tableView，只是给他传递不同的数据就可以了。）

示例图.png
二、单例模式：
应用场景：在程序运行期间，确保对于一个给定的类只有一个实例存在，这个实例有一个全局唯一的访问点，用于进行资源共享控制。
优势：使用简单，延时求值，易于跨模块。最主要的是因为只是创建一次，所以可以节省内存。
原则：单一职责原则
实例：[NSUserDefaults standardUserDefaults], [UIApplication sharedApplication], [UIScreen mainScreen], [NSFileManager defaultManager]，所有的这些方法都返回一个单例对象。
下面是一个使用了单例模式新建和获取实例的类模版，代码如下：
.h文件

@interface Singleton : NSObject
+ (Singleton *)sharedSingleton; <1>
@end

.m文件

#import "Singleton.h"
@implementation Singleton   
static Singleton *sharedSingleton = nil;<2>
+ (Singleton *)sharedSingleton{
    static dispatch_once_t once;<3>
    dispatch_once(&once,^{
        sharedSingleton = [[self alloc] init];<4>
        //只需要运行一次就可以满足需求的代码都可以写在这里。
    });
    return sharedSingleton;<5>
}

上述代码中有5小步，解释如下：

1. 声明一个可以新建和获取单个实例对象的方法
2. 声明一个static类型的类变量
3. 声明一个只执行一次的任务
4. 调用dispatch_once执行该任务指定的代码块，在该代码块中实例化上文声明的类变量
5. 返回在整个应用的生命周期中只会被实例化一次的变量
   以上就是iOS开发中单例模式的机制，

三、代理模式
应用场景：当一个类的某些功能需要由别的类来实现，但是又不确定具体会是哪个类实现。
优势：解耦合
敏捷原则：开放-封闭原则
实例：tableview的 数据源delegate，通过和protocol的配合，完成委托诉求。
自定义的delegate

四、观察者模式（一般分为：通知和KVO）
1、通知(notification)机制：Notification通知中心，注册通知中心，任何位置可以发送消息，注册观察者的对象可以接收。（比如：一个爱唱歌的人，喜欢跟着音乐播放器里的歌声来跟着哼哼，当播放器里进行切歌的时候，那么这个哼哼的曲调当然也就会跟着变化）。
第一步：注册通知，即告诉通知中心，我对啥通知感兴趣

[[NSNotificationCenter defaultCenter] addObserver: self  selector: @selector(hengheng) name: @"切歌了"  object: nil];

第二步：实现回调，如果有通知了，我需要干什么

- (void)callBack{
    NSLog(@"唱得不好听");
}

第三步：在程序任何一个地方都可以发送通知

 //发出通知
    [[NSNotificationCenter defaultCenter] postNotificationName:@"切歌了" object:self];

第四步（可选）：可以在需要的时候取消注册通知。

[[NSNotificationCenter defaultCenter] removeObserver:self name:@"切歌了" object:nil];

2、KVO：，键值对改变通知的观察者，平时基本没用过。
KVO是观察者设计模式中的一种实现方法。

五、策略模式（平时基本没用过。）
应用场景：定义算法族，封装起来，使他们之间可以相互替换。（在软件开发中也常常遇到类似的情况，实现某一个功能有多种算法或者 策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能 。如查找、排序等，一种常用的方法是硬编码(Hard Coding)在一个类中，如需要提供多种查找算法，可以将这些算法写到一个类中，在该类中提供多个方法，每一个方法对应一个具体的查找算法；当然也可以将这些查找算法封装在一个统一的方法中，通过if…else…或者 case 等条件判断语句来进行选择。这两种实现方法我们都可以称之为硬编码，如果需要增加一种新的查找算法，需要修改封装算法类的源代码；更换查找算法，也需要修改客户端调用代码。在这个算法类中封装了大量查找算法， 该类代码将较复杂，维护较为困难。如果我们将这些策略包含在客户端 ，这种做法更不可取，将导致客户端程序庞大而且难以维护，如果存在大量可供选择的算法时问题将变得更加严重。）
优势：使算法的变化独立于使用算法的用户
敏捷原则：接口隔离原则；多用组合，少用继承；针对接口编程，而非实现。
实例：排序算法，NSArray的sortedArrayUsingSelector。
注意事项：1，剥离类中易于变化的行为，通过组合的方式嵌入抽象基类
2，变化的行为抽象基类为，所有可变变化的父类
3，用户类的最终实例，通过注入行为实例的方式，设定易变行为
防止了继承行为方式，导致无关行为污染子类。完成了策略封装和可替换性。

六、工厂模式（平时基本没用过。）
应用场景：工厂方式创建类的实例，多与proxy模式配合，创建可替换代理类。
优势：易于替换，面向抽象编程，application只与抽象工厂和易变类的共性抽象类发生调用关系。
敏捷原则：DIP依赖倒置原则
实例：项目部署环境中依赖多个不同类型的数据库时，需要使用工厂配合proxy完成易用性替换
注意事项：项目初期，软件结构和需求都没有稳定下来时，不建议使用此模式，因为其劣势也很明显，
增 加了代码的复杂度，增加了调用层次，增加了内存负担。所以要注意防止模式的滥用。