生成器 和 抽象工厂 一样同属于创建型模式。
介绍
意图
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
适用性
- 当创建复杂对象的算法应该独立于该对象的组成部分已经它们的装配方式时。
- 当构造过程必须允许被构造的对象有不同的表示时。
结构
参与者
- Builder
为创建一个 Product 对象的各个部件指定抽象接口。
- ConcreteBuilder
实现 Builder 的接口已构造和装配该产品的各个部件。
定义并明确它所创建的表示。
提供一个检索产品的接口。
- Director
构造一个 Builder 接口对象。
- Product
协助
- 客户创建 Director 对象，比通过他想要的 Builder 对象进行配置。
- 一旦产品部件被生成，向导器就会通知生成器。
- 客户从生成器中检索产品。
效果
- 它使你可以改变一个产品的内部表示
Builder 对象提供给导向器一个构造产品的抽象接口。该接口使得生成器可以隐藏产品的表示和内部结构。
- 它将构造代码和表示代码分开
- 他可以对构造过程进行更精细的控制
Builder 模式与一下子就生成产品的创建型模式不同，它是在导向器控制下一步一步构造产品的。
实现
- 装配和构造接口
- 为什么产品没有抽象类
由于具体生成器生成的产品，它们的表示相差很大，以至于给不同的产品公共的父类并不现实。
- 在 Builder 中缺省的方法为空
示例
定义一个生成器 MazeBuilder
protocol MazeBuilder {
func buildMaze()
func buildRoom(n: Int)
func buildDoor(roomFrom: Int, roomTo: Int)
func getMaze() -> Maze?
}
extension MazeBuilder {
func buildMaze() {}
func buildRoom(n: Int) {}
func buildDoor(roomFrom: Int, roomTo: Int) { }
func getMaze() -> Maze? { return nil }
}
主要接口有：
- 创建迷宫接口
- 创建房间接口
- 创建门的接口
MazeBuilder 并不用来构建迷宫，它主要用来定义接口。
现在我们定义一个用来构建迷宫的类 StandarMazeBuilder 。
这里 StandarMazeBuilder 我选择使用 class, 因为生成器在协助中有一点 客户从生成器中检索产品。也就是说用户使用生成器的方法构造产品后，还可以使用通过现在生成器对象进行检索产品。这样使用引用类型是更好的选择。
class StandarMazeBuilder: MazeBuilder {
var currentMaze: Maze?
func buildMaze() {
currentMaze = Maze()
}
func buildRoom(n: Int) {
var room = Room(no: n)
room.setSide(dect: .east, site: Wall())
room.setSide(dect: .north, site: Wall())
room.setSide(dect: .south, site: Wall())
room.setSide(dect: .west, site: Wall())
currentMaze?.addRoom(room: room)
}
func commonWall(r1: Room, r2: Room) -> Direction {
return .north
}
func buildDoor(roomFrom: Int, roomTo: Int) {
var r1 = currentMaze!.getRoom(roomFrom)
var r2 = currentMaze!.getRoom(roomTo)
let d = Door(r1: r1, r2: r2)
r1.setSide(dect: commonWall(r1: r1, r2: r2), site: d)
r2.setSide(dect: commonWall(r1: r2, r2: r1), site: d)
}
func getMaze() -> Maze? {
return currentMaze
}
}
这里 commonWall 是个功能性操作，决定两个房间的公共墙壁的方位（为了简单处理我这里就固定返回一个值吧）
最后我们需要定义一个导向器。
struct MazeGame {
func createMaze(builder: MazeBuilder) -> Maze? {
builder.buildMaze()
builder.buildRoom(n: 1)
builder.buildRoom(n: 2)
builder.buildDoor(roomFrom: 1, roomTo: 2)
return builder.getMaze()
}
}
现在再看看如何使用这个生成器来构造迷宫。
let game = MazeGame()
let builder = StandarMazeBuilder()
game.createMaze(builder: builder)
let maze = builder.getMaze()
print("\(maze!)")
打印信息：
===========================
Maze room:
room_2 Room
north is Optional(Wall)
south is Optional(Wall)
east is Optional(Wall)
west is Optional(Wall)
room_1 Room
north is Optional(Wall)
south is Optional(Wall)
east is Optional(Wall)
west is Optional(Wall)
===========================
到现在生成器模式看上去好像没什么特别之处。
那接下来我们就来完成另外一个需求，我们不去构建迷宫，只对迷宫的构件进行计数。
这个看起来和原来用例构建迷宫的代码有则很大的差异。
但我们使用生成器模式就不用惧怕这样的差异。我们重新定义一个 CountingMazeBuilder 生成器就可以了。
class CountingMazeBuilder: MazeBuilder {
var doors = 0
var rooms = 0;
func buildDoor(roomFrom: Int, roomTo: Int) {
doors += 1
}
func buildRoom(n: Int) {
rooms += 1
}
func getCounts() -> (r: Int, d: Int) {
return (rooms, doors)
}
}
我们再看看用户如何使用这个生成器，代码视乎没有太大的变化。
let game = MazeGame()
let countingBuilder = CountingMazeBuilder()
game.createMaze(builder: countingBuilder)
let count = countingBuilder.getCounts()
print("The maze has \nrooms \(count.r) \ndoors \(count.d)")
打印信息：
The maze has
rooms 2
doors 1
最后来点总结
相比抽象工厂模式，生成器模式更擅长于对内部表示存在较大差异的产品定义统一的接口。使得构建代码和表示代码分离。
最最后 欢迎讨论、批评、指错。
