生成器模式是iOS设计模式中比较简单的一种模式，也经常拿来和抽象工厂作对比。首先我们说下什么事生成器模式。该模式由三个部分构成: 客户端-指导者-建造者。客户就是提具体需求的，例如我想要什么; 指导者类似承包商, 他来接收客户的要求，消化吸收后，协调各个建造者，告诉他们要造什么，之后建造者来负责具体的制造部分。总的来说，生成器模式就是为了分离逻辑和算法。这里的逻辑就是建造什么，也包含建造的顺序；算法就是建造者具体负责的那部分，即这个东西如何造出来。这里特别体现了设计模式的初衷: 解耦。
我们来看一个类图:
其中Director定义了construct方法，用来指导具体的builder；而Builder则是一个抽象接口，定义了build的方法，由具体builder实现，同时提供getResult方法返回给客户具体的产品。从时序图中我们也可以看到，是client最终向builder发送了getResult消息，而不是director。这时候不禁有了疑问，为什么不让director返回呢？如果这样的话，就违背了逻辑和算法分开的初衷，并且变成了类似抽象工厂的模式。生成器模式强调逻辑和算法分开是为了更好地解耦这两个部分，相同的builder在不同的director指导下可以生产出不同的产品，反之亦然，这样的处理提高了程序的灵活性和健壮性。下图是生成器和抽象工厂模式的对比:
在实际应用中，建造者和指导者是聚合的关系，指导者中包含建造者。建造者类似MVC中的Model，定义一些属性，一些建造方法(算法).例如游戏中玩家和敌人的CharacterBuider。而指导者就是一个具体类，例如ChasingGame(游戏名), 定义2个construct方法，例如createPlayer和createEnemy来向builder发送指令。完成构建后，builder返回一个装配好的人物类给客户端。
总的来说，生成器模式浅显易懂，比较tricky的部分就是和抽象工厂的区分以及何时使用该模式。(1. 构建过程需要以不同方式进行；2. 构建较为复杂的对象，创建算法独立于装配方式，如组合对象)
