iOS常用设计模式总结（一）
设计模式大概分成三类：
1.创建型：单例设计模式、抽象工厂设计模式
2.结构型：MVC 模式、装饰器模式、适配器模式、外观模式、组合模式
3.行为型：责任链设计模式、观察者设计模式，备忘录设计模式、命令设计模式
MVC模式：
涉及到的三个角色如下：
Model:
模型保存应用程序的数据，定义了怎么去操作它。例如在本应用中模型就是Album类。
View:
视图是模型的可视化表示以及用户交互的控件；基本上来说，所有的UIView对象以及它的子类都属于视图。在本应用中AlbumView代表了视图。
Controller:
控制器是一个协调所有工作的中介者（Mediator）。它访问模型中的数据并在视图中展示它们，同时它们还监听事件和根据需要操作数据。你可以猜猜哪个类是控制器吗？它正是：ViewController。
MVC遵循以下的原则：
在理想的状态下，视图应该和模型完全的分离。如果视图不依赖某个实际的模型，那么视图就可以被复用来展示不同模型的数据。
单例设计模式有如下特点：
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块中的代码将不会执行（因为它已经被执行了一次），你将得到原先已经初始化好的实例。
外观模式Facade：
特点：
- 外观模式针对复杂的子系统提供了单一的接口，不需要暴漏一些列的类和API给用户，你仅仅暴漏一个简单统一的API。
2.使用者完全不需要关心背后的复杂性。这个模式非常适合有一大堆很难使用或者理解的类的情况。
3.外观模式解耦了使用系统的代码和需要隐藏的接口和实现类。它也降低了外部代码对内部子系统的依赖性。当隐藏在门面之后的类很容易发生变化的时候，此模式就很有用了，因为当背后的类发生变化的时候，门面类始终保持了同样的API。
应用场景：
假如某个模块需要对一些数据做展示，这些数据的来源可能是不同数据库、可能是通过网络请求返回，总之载入数据的过程及其复杂，这时候可以合理运用外观模式，封装复杂的数据加载处理过程，对外公开简单的接口返回数据。
装饰器（Decorator）模式
装饰器模式在不修改原来代码的情况下动态的给对象（而不是类）增加新的行为和职责，它通过一个对象包装被装饰对象的方法来修改类的行为，这种方法可以做为子类化的一种替代方法。相对而言这种方式比子类继承更为灵活。
在Objective-C中，存在两种非常常见的实现:Category(类别）和Delegation（委托）。
注意:如果方法与原来类的方法重名了，或者与同样的类（甚至它的父类）的其它的扩展重名，那么运行期到底应该调用哪个方法是未定义的。当你仅仅是在扩展你自己写的类时，这没什么问题， 但是当你在扩展标准的Cocoa 或者Cocoa Touch类的时候，它可能会导致严重的问题。
简单工厂模式
初衷：在某个模块中，如果有大量的分配（new）释放（delete）某些对象操作。
这类操作如果过多，分散在各处，这样会非常难以管理，代码将会很乱，维护起来也很困难。
new操作经常要对应编写一些异常处理代码，这时编码变得极其混乱和臃肿。
在这种情况下，要解决这些问题，我们需要一个新的类。专门从事对象的建立和释放，之后，对象的各种操作，与这个类就不再有任何关系。
这个类即是工厂类，专门用于创建对象，向外暴露创建对象的接口，供外部调用。
工厂模式有一种非常形象的描述，建立对象的类就如一个工厂，而需要被建立的对象就是一个个产品；在工厂中加工产品，使用产品的人，
不用在乎产品是如何生产出来的。从软件开发的角度来说，这样就有效的降低了模块之间的耦合。
简单工厂模式示意图：
简单工厂模式有以下弱点：
1.如果要新增一个产品，这样必须在代码层次增加产品类别，不具有自动扩展的灵活性。而频繁多次修改曾经已经测试过的代码，在项目开发中是很忌讳的事情。
工厂方法模式
为了解决上述简单工厂模式的弱点，出现了工厂方法模式
简单说，工厂方法模式，就是针对不同的产品，使用不同的工厂类创建不同的工厂对象然后生产不同的产品。
也就是一个工厂类对应一类产品。
这样需要新建一类产品的时候，需要新建一个工厂类，同时对应扩展一个产品类
这种设计模式的缺点也是显而易见的：
1.每新增一个产品类，对应就要新建一个工厂类，如果产品比较多，必然会分配大量的工厂对象，这样维护的成本势必会增加。
2.既然每个产品的工厂类都彻底分开独立，这样某些可以复用的代码块将无法复用。
工厂方法模式：
为了解决工厂方法模式的上述缺陷，出现了抽象工厂模式
抽象工厂模式在一定的程度上借鉴了简单工厂模式和工厂方法模式的优点，同时抑制了其缺点。
简单说，抽象工厂在一定程度上对具有共性产品做了归类，并对应实现了生产该类产品工厂类。
此时的工厂类与工厂方法模式下的工厂类的主要区别在于，这种工厂类并不局限于创建某个特定类的产品，而是根据需要可以创建具体类型不同的产品。
抽象工厂模式示意图：
工厂模式总结：
应用场景:
1.在设计的初期，就考虑到产品在后期会进行大规模扩展的情况下，应当使用工厂方法模式；
2.产品结构较复杂的情况下，建议使用工厂方法模式；
3.工厂方法模式适用于产品种类结构单一的场合，为一类产品提供创建的接口；
4.而抽象工厂方法适用于产品种类结构多的场合，主要用于创建一组（有多个种类）相关的产品，为它们提供创建的接口；就是当具有多个抽象角色时，抽象工厂便可以派上用场。
5.至于简单工厂模式，适合类型单一，但是多个场合下频繁创建销毁的情况，当后期需要大规模扩展时，不适宜使用简单工厂模式。