生成器模式是iOS設(shè)計(jì)模式中比較簡(jiǎn)單的一種模式，也經(jīng)常拿來(lái)和抽象工廠作對(duì)比。首先我們說(shuō)下什么事生成器模式。該模式由三個(gè)部分構(gòu)成: 客戶端-指導(dǎo)者-建造者?？蛻艟褪翘峋唧w需求的，例如我想要什么; 指導(dǎo)者類(lèi)似承包商, 他來(lái)接收客戶的要求，消化吸收后，協(xié)調(diào)各個(gè)建造者，告訴他們要造什么，之后建造者來(lái)負(fù)責(zé)具體的制造部分?？偟膩?lái)說(shuō)，生成器模式就是為了分離邏輯和算法。這里的邏輯就是建造什么，也包含建造的順序；算法就是建造者具體負(fù)責(zé)的那部分，即這個(gè)東西如何造出來(lái)。這里特別體現(xiàn)了設(shè)計(jì)模式的初衷: 解耦。
我們來(lái)看一個(gè)類(lèi)圖:
其中Director定義了construct方法，用來(lái)指導(dǎo)具體的builder；而Builder則是一個(gè)抽象接口，定義了build的方法，由具體builder實(shí)現(xiàn)，同時(shí)提供getResult方法返回給客戶具體的產(chǎn)品。從時(shí)序圖中我們也可以看到，是client最終向builder發(fā)送了getResult消息，而不是director。這時(shí)候不禁有了疑問(wèn)，為什么不讓director返回呢？如果這樣的話，就違背了邏輯和算法分開(kāi)的初衷，并且變成了類(lèi)似抽象工廠的模式。生成器模式強(qiáng)調(diào)邏輯和算法分開(kāi)是為了更好地解耦這兩個(gè)部分，相同的builder在不同的director指導(dǎo)下可以生產(chǎn)出不同的產(chǎn)品，反之亦然，這樣的處理提高了程序的靈活性和健壯性。下圖是生成器和抽象工廠模式的對(duì)比:
在實(shí)際應(yīng)用中，建造者和指導(dǎo)者是聚合的關(guān)系，指導(dǎo)者中包含建造者。建造者類(lèi)似MVC中的Model，定義一些屬性，一些建造方法(算法).例如游戲中玩家和敵人的CharacterBuider。而指導(dǎo)者就是一個(gè)具體類(lèi)，例如ChasingGame(游戲名), 定義2個(gè)construct方法，例如createPlayer和createEnemy來(lái)向builder發(fā)送指令。完成構(gòu)建后，builder返回一個(gè)裝配好的人物類(lèi)給客戶端。
總的來(lái)說(shuō)，生成器模式淺顯易懂，比較tricky的部分就是和抽象工廠的區(qū)分以及何時(shí)使用該模式。(1. 構(gòu)建過(guò)程需要以不同方式進(jìn)行；2. 構(gòu)建較為復(fù)雜的對(duì)象，創(chuàng)建算法獨(dú)立于裝配方式，如組合對(duì)象)
