常见代码问题:
1、代码膨胀，代码达百万行甚至千万行。
2、代码的理解和调试占用较多时间。
3、代码交互复杂、模块相互引用、接口网状分布。
4、代码难以修改，易引入新的问题，改代码的时候战战兢兢。
5、类、方法太复杂，代码行太多。
6、重复代码、无效代码太多。
7、接口不明确。
为什么要用设计模式：
设计模式使代码编制真正工程化；
设计模式是软件工程的基石脉络，如同大厦的结构一样。
设计模式遵循的原则：
1、一个类应该只有一个发生变化的原因。
2、如果调用的是父类的话，那么换成子类也完全可以运行。
3、抽象不应该依赖于细节，细节应当依赖于抽象。面向接口编程，而不是面向实现编程。
4、使用多个专门的接口比使用单一的总接口要好。
客户端不应该依赖它不需要的接口；
一个类对另一个类的依赖应该建立在最小的接口上。
5、模块应对扩展开放，而对修改关闭。
6、一个对象应当对其他对象有尽可能少的了解。每个类尽量减少对其他类的依赖。
1.创建型：
单例设计模式
抽象工厂设计模式
2.结构型：
MVC 模型：
装饰器模式：
适配器模式:Category(类别）和Delegation（委托）
外观模式:外观模式针对复杂的子系统提供了单一的接口，不需要暴漏一些列的类和API给用户，你仅仅暴漏一个简单统一的API。
组合模式:
3.行为型：
责任链设计模式:
观察者设计模式:Notification(通知)机制 和 KVO机制
备忘录设计模式:
命令设计模式:
设计模式：
实例方法，类方法，便利构造方法
extention(延展) ，Category(类别）
KVC
KVO：观察者的注册是在被观察者的内部进行的，不同于通知机制（由观察者自己注册），需要被观察者和观察者同时实现一个协议：NSKeyValueObserving，被观察者通过addObserver:forKeypath:options:context方法注册观察者，以及要被观察的属性。
Delegate(代理)：java中的接口，类可以实现或不实现协议（接口）中的方法。通过此种方式，达到最大的解耦目的，方便项目的扩展。
Sington(单例)
Notification(通知)机制
block（回调）
何为单例模式：一个类在系统中只有一个实例对象。通过全局的一个入口点对这个实例对象进行访问。整个应用或系统只能有该类的一个实例
单例模式静态类图：
技术要点：
1、某个类只能有一个实例
2、它必须自行创建这个实例
3、它必须向整个系统提供这个实例
何时使用单例模式：
1、只能共享而不能复制的资源，如CLLocationManager类。
2、类必须有一个实例，而且必须从一个为人熟知的访问点对其进行访问，比如工 厂方法。
在Objective-C中实现单例模式：
1、如何保证类只创建一个实例？因为OC中所有方法都是共有的。
Apple官方文档里面关于单例(Singleton)的示范代码：
static MyGizmoClass *sharedGizmoManager = nil;
(MyGizmoClass*)sharedManager
{
if (sharedGizmoManager == nil) {
sharedGizmoManager = [[super allocWithZone:NULL] init];
}return sharedGizmoManager;
}(id)allocWithZone:(NSZone *)zone //避免通过alloc和init获取一个实例
{
return [[self sharedManager] retain];
}
2、克隆：如果该类实现了NSCopying协议，则需要重写copyWithZone。
3、线程安全：如果是多线程的话，可以使用@synchronized、NSLock或者dispatch_once_t。
第二种方式：
//Singleton.h
@interface Singleton : NSObject
- (Singleton *)sharedSingleton; <1>
@end
/***************************************************************/
//Singleton.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>
//dosometing
});
return sharedSingleton;<5>
}
<1>声明一个可以新建和获取单个实例对象的方法
<2>声明一个static类型的类变量
<3>声明一个只执行一次的任务
<4>调用dispatch_once执行该任务指定的代码块，在该代码块中实例化上文声明的类变量
<5>返回在整个应用的生命周期中只会被实例化一次的变量
在Cocoa Touch框架中使用单例模式：举例如下：
1、UIApplication，可通过sharedApplication类方法访问。
2、UIAccelerometer，可通过sharedAccelerometer访问。
3、NSFileManager，可通过defaultFileManager访问。
4、NSBundle类提供了 +mainBunle方法获取NSBundle单例
5、NSNotificationCenter提供了 ＋defaultCenter方法创建和获取NSNotificationCenter单例（PS：该类还遵循了另一个重要的设计模式：观察者模式）
6，NSUserDefaults类提供了 ＋defaultUserDefaults方法去创建和获取NSUserDefaults单例
简单工厂模式：
这个类即是工厂类，专门用于创建对象，向外暴露创建对象的接口，供外部调用。工厂模式有一种非常形象的描述，建立对象的类就如一个工厂，而需要被建立的对象就是一个个产品；在工厂中加工产品，使用产品的人，不用在乎产品是如何生产出来的。
简单工厂模式中，工厂类是整个模式的关键，其包含必要的判断逻辑，能够根据外界给定的信息，决定究竟创建哪个类的实例，外界可以不用去关注对象的创建，仅需要负责“消费”对象就可以了。
专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类，又称为静态工厂方法，我们习惯称这个为：实例方法。
优缺点：
1、优点：明确区分了责任，有利于结构的优化。从面向实现类编码转换为面向接口编程。
2、缺点：集中了所有实例的创建逻辑，违反了高内聚的责任分配原则，当系统的具体产品类不断增多时，工厂类中条件判断过多，不利于扩展及维护。
工厂方法模式：
定义创建对象的接口，让子类决定实例化哪个类，工厂方法使得一个类的实例化延迟到其子类。
简单说，工厂方法模式，就是针对不同的产品，使用不同的工厂类创建不同的工厂对象然后生产不同的产品。
何时使用工厂方法：
1、编译时无法准确预期要创建的对象的类。
2、类想让其子类决定在运行时创建什么。
工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。
1.每新增一个产品类，对应就要新建一个工厂类，如果产品比较多，必然会分配大量的工厂对象，增加了额外的开发量，这样维护的成本势必会增加。
2.既然每个产品的工厂类都彻底分开独立，这样某些可以复用的代码块将无法复用。
何为抽象工厂：
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
简单说，抽象工厂在一定程度上对具有共性产品做了归类，并对应实现了生产该类产品工厂类。
此时的工厂类与工厂方法模式下的工厂类的主要区别在于，这种工厂类并不局限于创建某个特定类的产品，而是根据需要可以创建具体类型不同的产品。
何时使用抽象工厂：
1、通过对象组合创建抽象产品。
2、创建多系列产品
抽象工厂模式是对象的创建模式，它是工厂方法模式的进一步推广。
工厂模式总结：
应用场景:
1.在设计的初期，就考虑到产品在后期会进行大规模扩展的情况下，应当使用工厂方法模式；
2.产品结构较复杂的情况下，建议使用工厂方法模式；
3.工厂方法模式适用于产品种类结构单一的场合，为一类产品提供创建的接口；
4.而抽象工厂方法适用于产品种类结构多的场合，主要用于创建一组（有多个种类）相关的产品，为它们提供创建的接口；就是当具有多个抽象角色时，抽象工厂便可以派上用场。
5.至于简单工厂模式，适合类型单一，但是多个场合下频繁创建销毁的情况，当后期需要大规模扩展时，不适宜使用简单工厂模式。
