[原创]设计模式之比较记忆法(1) - 设计模式

Creational Patterns篇之
Abstract Factory模式与Builder模式

简记为A模式和B模式

之所以将这两个模式放在一起进行比较记忆, 是因为两者都专注于构造一组实例, 但是, 两者对这组实例各自的要求又不相同.

比如, 现在要求生产一辆”自行车”, 它由车轮和车架组成. 那么一辆”自行车”就可以看作是一个由车轮和车架组成的实例集合(之所以加上引号, 是因为也可能只是生产出由车轮和车架2个元件的集合, 并未组装成真正的自行车). 有两个生产厂家, 都可以生产这2种元件. 那么Abstract Factory模式与Builder模式的区别在哪儿呢?

先看Abstract Factory模式. Abstract Factory模式是用来定义一种约束的, 该约束用来说明一辆”自行车”的车轮由哪个厂商生产, 而车架又由哪个厂商生产. 比如, 一种约束可能要求车轮和车架都由厂家1生产, 或者另外一种约束可能要求车轮和车架都由厂家2生产. 要注意的是, Abstract Factory模式只是规定了元件以什么样的风格生产, 但并没有规定元件以什么样的方式组装. 也就是说使用Abstract Factory模式产生的元件集合(能够组装成一辆”自行车”的车轮和车架)是符合要求的, 但是该集合中的元件都是未组装的,零散的.

Abstract Factory模式的UML结构图为:

在该图中,

抽象类AbstractProductA定义了产品A(相当于车轮)的接口, 类ProductA1和类ProductA2则分别是由厂商1和厂商2生产的产品A. 抽象类AbstractProductB定义了产品B(相当于车架)的接口, 类ProductB1和类ProductB2则分别是由厂商1和厂商2生产的产品B.
抽象类AbstractFactory定义了实例集合由产品1和产品2组成(相当于”自行车”由车轮和车架组成), 而子类ConcreteFacory1和ConcreteFactory2则分别定义了两种约束:ConcreteFacory1只生成由厂商1生产的车轮和车架的”自行车”(没有组装);ConcreteFacory2只生成由厂商2生产的车轮和车架的”自行车”(没有组装).

那么, Builder模式呢?Builder模式生产自行车时(注意, 没有双引号, 它确实可以组装成一辆自行车)一方面注重各个元件的生产, 另一方面它还负责将各个元件按照一定的步骤组装起来, 从而真正生产一辆自行车(当然, 是不是真正意义上的自行车, 要看组装方式是否正确), 而不仅仅是一堆零件. 其实这正说明了Builder模式的作用:将自行车的各个元件的生产工艺与自行车的组装方法分离.

Builder模式的UML结构图为:

在该图中,

父类Builder定义了需要构造的各个部分(元件)的接口, 而子类ConcreteBuilder则根据需要定义具体的实现方法;
类director包含了方法Constructor(), 它定义了各个部分(元件)的组装方式. 它只使用父类Builder的接口, 但是可以利用语言的继承特性, 运行时动态绑定到具体的ConcreteBuilder上.

小结

相似点:

A模式与B模式都试图构造一个实例的集合(一组实例).

区别及各自优点:

A模式构造的实例的集合中的各个实例之间关系是松散的,

A模式可以定义一个规则(或约束), 使得这组集中的每个实例都遵守.

其优点就在于, 可以避免由于单个生成实例而破坏这种规则.

B模式构造的实例的集合中的各个实例(元件)之间关系是紧密的, 它们联合起来

组成一个更大的实体.

B模式的优点在于, 它将各个元件的具体生成方式与元件之间的组合方式分离开来.