浅谈Objective-C设计模式（Design Pattern）import "Singleton.h"

常见代码问题: 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.至于简单工厂模式，适合类型单一，但是多个场合下频繁创建销毁的情况，当后期需要大规模扩展时，不适宜使用简单工厂模式。