建立型設計模式

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"; 

優勢：

• 能夠利用原型模式簡化對象的建立過程，尤爲是對一些建立過程繁瑣，包含對象層級比較多的對象來講，使用原型模式能夠節約系統資源，提升對象生成的效率。
• 能夠很方便得經過改變值來生成新的對象：有些對象之間的差異可能只在於某些值的不一樣；用原型模式能夠快速複製出新的對象並手動修改值便可。

缺點：

• 對象包含的全部對象都須要配備一個克隆的方法，這就使得在對象層級比較多的狀況下，代碼量會很大，也更加複雜。