建立型设计模式

1 简单工厂模式

简单工厂模式(Simple Factory Pattern)：专门定义一个类（工厂类）来负责建立其余类的实例。能够根据建立方法的参数来返回不一样类的实例，被建立的实例一般都具备共同的父类。

 

 

举例：

简单工厂模式像一个代工厂，一个工厂能够生产多种产品。举个例子，一个饮料加工厂同时帮百事可乐和可口可乐生产，加工厂根据输入参数Type来生产不一样的产品。

// 可乐抽象类
@interface Cola : NSObject
@end

// 可口可乐产品类
@interface CocaCola : Cola
@end

// 百事可乐产品类
@interface PesiCola : Cola
@end

// 简单工厂实现
@implementation SimpleFactory

+ (Cola *)createColaWithType:(NSInteger)type { switch (type) { case 0: return [CocaCola new]; case 1: return [PesiCola new]; default: return nil; break; } } @end 

// 0 生产可口可乐
Cola *cocaCola = [SimpleFactory createColaWithType:0];

// 1 生产百事可乐
Cola *pesiCola = [SimpleFactory createColaWithType:1];

优势：

• 使用者只须要给工厂类传入一个正确的约定好的参数，就能够获取你所须要的对象，而不须要知道其建立细节，必定程度上减小系统的耦合。
• 客户端无须知道所建立的具体产品类的类名，只须要知道具体产品类所对应的参数便可，减小开发者的记忆成本。

缺点：

• 若是业务上添加新产品的话，就须要修改工厂类原有的判断逻辑，这实际上是违背了开闭原则的。
• 在产品类型较多时，有可能形成工厂逻辑过于复杂。因此简单工厂模式比较适合产品种类比较少并且增多的几率很低的状况。

2 工厂方法模式

工厂方法模式(Factory Method Pattern)又称为工厂模式，工厂父类负责定义建立产品对象的公共接口，而工厂子类则负责生成具体的产品对象，即经过不一样的工厂子类来建立不一样的产品对象。

 

 

举例：

工厂方法和简单工厂有一些区别，简单工厂是由一个代工厂生产不一样的产品，而工厂方法是对工厂进行抽象化，不一样产品都由专门的具体工厂来生产。可口可乐工厂专门生产可口可乐，百事可乐工厂专门生产百事可乐。

// 工厂抽象类
@implementation Factory
+ (Cola *)createCola {
    return [Cola new]; } @end // 可口可乐工厂 @implementation CocaColaFactory + (Cola *)createCola { return [CocaCola new]; } @end // 百事可乐工厂 @implementation PesiColaFactory + (Cola *)createCola { return [PesiCola new]; } @end 

// 根据不一样的工厂类生产不一样的产品
Cola *pesiCola = [PesiColaFactory createCola];
Cola *cocaCola = [CocaColaFactory createCola];
复制代码

优势：

• 用户只须要关心其所需产品对应的具体工厂是哪个便可，不须要关心产品的建立细节，也不须要知道具体产品类的类名。
• 当系统中加入新产品时，不须要修改抽象工厂和抽象产品提供的接口，也无须修改客户端和其余的具体工厂和具体产品，而只要添加一个具体工厂和与其对应的具体产品就能够了，符合了开闭原则。

缺点：

• 当系统中加入新产品时，除了须要提供新的产品类以外，还要提供与其对应的具体工厂类。所以系统中类的个数将成对增长，增长了系统的复杂度。

3 抽象工厂模式

抽象工厂模式(Abstract Factory Pattern)：提供一个建立一系列相关或相互依赖对象的接口，而无须指定它们具体的类。

 

 

举例：

抽象工厂和工厂方法不一样的地方在于，生产产品的工厂是抽象的。举例，可口可乐公司生产可乐的同时，也须要生产装可乐的瓶子和箱子，瓶子和箱子也是可口可乐专属定制的，一样百事可乐公司也会有这个需求。这个时候咱们的工厂不只仅是生产可乐饮料的工厂，还必须同时生产同一主题的瓶子和箱子，因此它是一个抽象的主题工厂，专门生产同一主题的不一样商品。

// 可乐抽象类和派生类
@interface Cola : NSObject
@end
@interface CocaCola : Cola
@end
@interface PesiCola : Cola
@end

// 瓶子抽象类和派生类
@interface Bottle : NSObject
@end
@interface CocaColaBottle : Bottle
@end
@interface PesiColaBottle : Bottle
@end

// 箱子抽象类和派生类
@interface Box : NSObject
@end
@interface CocaColaBox : Box
@end
@interface PesiColaBox : Box
@end

// 工厂抽象类
@implementation Factory

+ (Cola *)createCola {
    return [Cola new]; } + (Bottle *)createBottle { return [Bottle new]; } + (Box *)createBox { return [Box new]; } @end // 可口可乐主题工厂 @implementation CocaColaFactory + (CocaCola *)createCola { return [CocaCola new]; } + (CocaColaBottle *)createBottle { return [CocaColaBottle new]; } + (CocaColaBox *)createBox { return [CocaColaBox new]; } @end // 百事可乐主题工厂 @implementation PesiColaFactory + (PesiCola *)createCola { return [PesiCola new]; } + (PesiColaBottle *)createBottle { return [PesiColaBottle new]; } + (PesiColaBox *)createBox { return [PesiColaBox new]; } @end 

// 可口可乐主题
Cola *cocaCola = [CocaColaFactory createCola];
Bottle *cocaColaBottle = [CocaColaFactory createBottle];
Box *cocaColaBox = [CocaColaFactory createBox];

// 百事可乐主题
Cola *pesiCola = [PesiColaFactory createCola];
Bottle *pesiColaBottle = [PesiColaFactory createBottle];
Box *pesiColaBox = [PesiColaFactory createBox];

优势：

• 具体产品在应用层代码隔离，不须要关心产品细节。只须要知道本身须要的产品是属于哪一个工厂的便可 当一个产品族中的多个对象被设计成一块儿工做时，它可以保证客户端始终只使用同一个产品族中的对象。这对一些须要根据当前环境来决定其行为的软件系统来讲，是一种很是实用的设计模式。

缺点：

• 规定了全部可能被建立的产品集合，产品族中扩展新的产品困难，须要修改抽象工厂的接口。

4 单例模式

单例模式(Singleton Pattern)：单例模式确保某一个类只有一个实例，并提供一个访问它的全剧访问点。

举例：

单例模式下，对应类只能生成一个实例。就像一个王国只能有一个国王，一旦王国里的事务多起来，这惟一的国王也容易职责太重。

@implementation Singleton

+ (instancetype)shareInstance {
    static Singleton *shareInstance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        shareInstance = [[Singleton alloc] init];
    });
    return shareInstance; } @end 

优势：

• 提供了对惟一实例的受控访问。由于单例类封装了它的惟一实例，因此它能够严格控制客户怎样以及什么时候访问它。
• 由于该类在系统内存中只存在一个对象，因此能够节约系统资源。

缺点：

• 因为单例模式中没有抽象层，所以单例类很难进行扩展。
• 对于有垃圾回收系统的语言 Java，C# 来讲，若是对象长时间不被利用，则可能会被回收。那么若是这个单例持有一些数据的话，在回收后从新实例化时就不复存在了。

5 生成器模式

生成器模式(Builder Pattern)：也叫建立者模式，它将一个复杂对象的构建与它的表示分离，使得一样的构建过程能够建立不一样的表示。

 

 

举例：

生成器模式将复杂的建立逻辑进行分割，例如生产汽车，分步骤建立安装不一样的零件。若是建立逻辑简单则没有拆分的必要。

// 汽车生产器
@interface Builder : NSObject

+ (void)buildEngine;
+ (void)buildWheel;
+ (void)buildBody;

@end

// 建立过程进行拆分
Builder *builder = [Builder new];
[builder buildBody];
[builder buildWheel];
[builder buildEngine];

优势：

• 客户端没必要知道产品内部组成的细节，将产品自己与产品的建立过程解耦，使得相同的建立过程能够建立不一样的产品对象。
• 每个具体建造者都相对独立，而与其余的具体建造者无关，所以能够很方便地替换具体建造者或增长新的具体建造者， 用户使用不一样的具体建造者便可获得不一样的产品对象 。
• 增长新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭原则”。
• 能够更加精细地控制产品的建立过程 。将复杂产品的建立步骤分解在不一样的方法中，使得建立过程更加清晰，也更方便使用程序来控制建立过程。

缺点：

• 建造者模式所建立的产品通常具备较多的共同点，其组成部分类似，若是产品之间的差别性很大，则不适合使用建造者模式，所以其使用范围受到必定的限制。
• 若是产品的内部变化复杂，可能会致使须要定义不少具体建造者类来实现这种变化，致使系统变得很庞大。

6 原型模式

原型模式（Prototype Pattern）: 使用原型实例指定待建立对象的类型，而且经过复制这个原型来建立新的对象。

举例：

原型模式就像复印技术，根据原对象复印出一个新对象，并根据需求对新对象进行微调。

@interface Student : NSObject

@property (nonatomic, copy) NSString *name;
@property (nonatomic, copy) NSString *age;
@property (nonatomic, copy) NSString *class;
@property (nonatomic, copy) NSString *school;

@end

// 原对象
Student *lily = [Student alloc] init];
lily.name = @"lily"; lily.age = @"13"; lily.class = @"五年一班"; lily.school = @"实现学校"; // 复制原对象 Student *tom = [lily copy]; // 在原对象基础上微调 tom.name = @"tom"; 

优势：

• 能够利用原型模式简化对象的建立过程，尤为是对一些建立过程繁琐，包含对象层级比较多的对象来讲，使用原型模式能够节约系统资源，提升对象生成的效率。
• 能够很方便得经过改变值来生成新的对象：有些对象之间的差异可能只在于某些值的不一样；用原型模式能够快速复制出新的对象并手动修改值便可。

缺点：

• 对象包含的全部对象都须要配备一个克隆的方法，这就使得在对象层级比较多的状况下，代码量会很大，也更加复杂。