iOS常用的设计模式
设计模式大概分成三类：
1.创建型：单例设计模式、抽象工厂设计模式
2.结构型：MVC 模式、装饰器模式、适配器模式、外观模式、组合模式
3.行为型：责任链设计模式、观察者设计模式，备忘录设计模式、命令设计模式
（一）代理模式
Delegate 的定义：
（1）Delegate 是一个对象， 其类型为 id (anonymous type: 匿名类型)；
（2） Delegate 的引用通常是一个实例变量 （instance variable）， 命名为 delegate；
（3）Delegate 内所用的方法是 访问模式 （Accessors pattern）
Cocoa Touh 的很多类都不同程度地用到Delgete。 比如： NSTextField， NSTableView。 其中 NSTableView 还用到了 Data Source。
其实，Data Source 也是一种委托。 Data Source 减少了 View 与 Model 之间的耦合性。 其中 ， NSAppplication 实现了几十个委托方法。
Delegate 使用的注意事项：
Delegate 是一个 ID 类型的对象， 同样存在创建和释放问题。 对于Data Source ， 只有Data Source的使用者 （比如Table View）释放后， Data Souce 才能被释放。 否则， 就会出现crash。 因为在table view 获取数据时， 数据已经不见了。
Delegate 可用在多个场景下，比如对象间的数据交互， 不同视图之间的行为交互。 若仅仅是数据交互， 可实现的方法还有很多。Delegate 尤其适用于视图之间的行为交互。
优势：解耦合
敏捷原则：开放-封闭原则
实例：tableview的 数据源delegate，通过和protocol的配合，完成委托诉求。
（二）观察者模式
应用场景：一般为model层对，controller和view进行的通知方式，不关心谁去接收，只负责发布信息。优势：解耦合
敏捷原则：接口隔离原则，开放-封闭原则
实例：Notification通知中心，注册通知中心，任何位置可以发送消息，注册观察者的对象可以接收。
kvo，键值对改变通知的观察者，平时基本没用过。（ KVO、通知 ：不是设计模式，是基于观察者设计模式的一种机制。）
（三）MVC模式
Model:模型保存应用程序的数据，定义了怎么去操作它。
View:视图是模型的可视化表示以及用户交互的控件；基本上来说，所有的UIView对象以及它的子类都属于视图。
Controller:控制器是一个协调所有工作的中介者（Mediator）。它访问模型中的数据并在视图中展示它们，同时它们还监听事件和根据需要操作数据。
MVC遵循以下的原则：在理想的状态下，视图应该和模型完全的分离。如果视图不依赖某个实际的模型，那么视图就可以被复用来展示不同模型的数据。（敏捷原则：对扩展开放-对修改封闭）
应用场景：是一中非常古老的设计模式，通过数据模型，控制器逻辑，视图展示将应用程序进行逻辑划分。优势：使系统，层次清晰，职责分明，易于维护
实例：model-即数据模型，view-视图展示，controller进行UI展现和数据交互的逻辑控制。（四）单例模式
单例设计模式有如下特点：
1.单例设计模式确保对于一个给定的类只有一个实例存在，这个实例有一个全局唯一的访问点。
2.它通常采用延迟加载的方式在第一次用到实例的时候再去创建它。
[NSUserDefaults standardUserDefaults], [UIApplication sharedApplication], [UIScreen mainScreen], [NSFileManager defaultManager]，所有的这些方法都返回一个单例对象
单例模式实现步骤：
1.声明一个静态变量去保存类的实例，确保它在类中的全局可用性。
2.声明一个静态变量dispatch_once_t ,它确保初始化器代码只执行一次
3.使用Grand Central Dispatch(GCD)执行初始化LibraryAPI变量的block.这 正是单例模式的关键：一旦类已经被初始化，初始化器永远不会再被调用。
下一次你调用sharedInstance的时候，dispatch_once块中的代码将不会执行（因为它已经被执行了一次），你将得到原先已经初始化好的实例。
优势：使用简单，延时求值，易于跨模块
敏捷原则：单一职责原则
实例：[UIApplication sharedApplication]。
注意事项：确保使用者只能通过 getInstance方法才能获得，单例类的唯一实例。
java，C++中使其没有公有构造函数，私有化并覆盖其构造函数。
object c中，重写allocWithZone方法，保证即使用户用 alloc方法直接创建单例类的实例，返回的也只是此单例类的唯一静态变量。
（五）策略模式
应用场景：定义算法族，封装起来，使他们之间可以相互替换。优势：使算法的变化独立于使用算法的用户
敏捷原则：接口隔离原则；多用组合，少用继承；针对接口编程，而非实现。
实例：排序算法，NSArray的sortedArrayUsingSelector；经典的鸭子会叫，会飞案例。
注意事项：1，剥离类中易于变化的行为，通过组合的方式嵌入抽象基类
2，变化的行为抽象基类为，所有可变变化的父类
3，用户类的最终实例，通过注入行为实例的方式，设定易变行为
防止了继承行为方式，导致无关行为污染子类。完成了策略封装和可替换性。
（六）工厂模式
工厂方法模式：定义创建对象的接口，让子类决定实例化哪一个类。工厂方法使得一个类的实例化延迟到其子类。
优势：易于替换，面向抽象编程，application只与抽象工厂和易变类的共性抽象类发生调用关系。
敏捷原则：DIP依赖倒置原则
实例：项目部署环境中依赖多个不同类型的数据库时，需要使用工厂配合proxy完成易用性替换
注意事项：项目初期，软件结构和需求都没有稳定下来时，不建议使用此模式，因为其劣势也很明显，
增 加了代码的复杂度，增加了调用层次，增加了内存负担。所以要注意防止模式的滥用。
//通过工厂方法创建类的实现举例
- (id)initWithName:(NSString*)name{
if(self = [super init]){
self.name = name;
//添加初始化相关细节
...
}
return self;
}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
2、定义生成器父类(例如:AnimalGenerator)和各个生成器子类(例如:DogGenerator、CarGenerator)。
3、生成器父类中创建工厂方法、各个生成器子类中重载该方法
//AnimalGenerator中工厂方法
- (Animla*)animalWithName:(NSString*)name{
return [[Animal alloc] initWithName:name];
}
//DogGenerator对AnimalGenerator中工厂方法的重载
- (Animal*)animalWithName:(NSString*)name{
return [[Dog alloc] initWitName:name];
}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
4、使用
DogGenerator *dogGenerator = [[DogGenerator alloc] init];
//不同生成器创建不同的动物
Animal *dog = [[dogGenerator animalWithName:@"小七"]];- 1
- 2
- 3
七、外观模式Facade：
特点：
1. 外观模式针对复杂的子系统提供了单一的接口，不需要暴漏一些列的类和API给用户，你仅仅暴漏一个简单统一的API。
2.使用者完全不需要关心背后的复杂性。这个模式非常适合有一大堆很难使用或者理解的类的情况。
3.外观模式解耦了使用系统的代码和需要隐藏的接口和实现类。它也降低了外部代码对内部子系统的依赖性。当隐藏在门面之后的类很容易发生变化的时候，此模式就很有用了，因为当背后的类发生变化的时候，门面类始终保持了同样的API。
应用场景：
假如某个模块需要对一些数据做展示，这些数据的来源可能是不同数据库、可能是通过网络请求返回，总之载入数据的过程及其复杂，这时候可以合理运用外观模式，封装复杂的数据加载处理过程，对外公开简单的接口返回数据。
八、装饰器（Decorator）模式
装饰器模式在不修改原来代码的情况下动态的给对象（而不是类）增加新的行为和职责，它通过一个对象包装被装饰对象的方法来修改类的行为，这种方法可以做为子类化的一种替代方法。相对而言这种方式比子类继承更为灵活。
在Objective-C中，存在两种非常常见的实现:Category(类别）和Delegation（委托）。
注意:如果方法与原来类的方法重名了，或者与同样的类（甚至它的父类）的其它的扩展重名，那么运行期到底应该调用哪个方法是未定义的。当你仅仅是在扩展你自己写的类时，这没什么问题， 但是当你在扩展标准的Cocoa 或者Cocoa Touch类的时候，它可能会导致严重的问题。