Builder 设计模式和 Factory 设计模式有什么区别？
哪一个更有利，为什么？
如果我想测试和比较 / 对比这些模式，如何将我的发现表示为图形？
对于设计模式，通常没有适用于所有情况的 “更有利” 的解决方案。这取决于您需要实现的内容。
从维基百科：
- Builder 致力于逐步构建一个复杂的对象。抽象工厂强调一系列产品对象（简单或复杂）。 Builder 将产品退回作为最后一步，但是就抽象工厂而言，产品将立即退回。
- 生成器通常会生成一个复合。
- 通常，设计始于使用工厂方法（不那么复杂，更可定制的子类激增），随着设计师发现需要更多灵活性的地方，它们逐渐发展为抽象工厂，原型或生成器（更灵活，更复杂）。
- 有时，创建模式是互补的：Builder 可以使用其他模式之一来实现要构建的组件。抽象工厂，构建器和原型可以在其实现中使用 Singleton。
维基百科关于工厂设计模式的条目： http://en.wikipedia.org/wiki/Factory_method_pattern
有关构建器设计模式的 Wikipedia 条目： http://en.wikipedia.org/wiki/Builder_pattern
工厂只是围绕构造函数的包装函数（可能是另一个类中的包装函数）。关键区别在于，工厂方法模式要求将整个对象构建在单个方法调用中，并且所有参数都在一行中传递。最终的对象将被返回。
另一方面，构建器模式实质上是一个包装器对象，它包装您可能希望传递给构造器调用的所有可能参数。这使您可以使用 setter 方法来缓慢地建立参数列表。构建器类上的另一种方法是 build（）方法，该方法只是将构建器对象传递到所需的构造函数中，并返回结果。
在像 Java 这样的静态语言中，当您拥有多个（可能是可选的）参数时，这变得尤为重要，因为它避免了对所有可能的参数组合都具有伸缩构造函数的需求。此外，构建器还允许您使用 setter 方法来定义只读或私有字段，在调用构造函数后，这些字段不能直接修改。
基本工厂示例
// Factory
static class FruitFactory {
static Fruit create(name, color, firmness) {
// Additional logic
return new Fruit(name, color, firmness);
}
}
// Usage
Fruit fruit = FruitFactory.create("apple", "red", "crunchy");基本生成器示例
// Builder
class FruitBuilder {
String name, color, firmness;
FruitBuilder setName(name) { this.name = name; return this; }
FruitBuilder setColor(color) { this.color = color; return this; }
FruitBuilder setFirmness(firmness) { this.firmness = firmness; return this; }
Fruit build() {
return new Fruit(this); // Pass in the builder
}
}
// Usage
Fruit fruit = new FruitBuilder()
.setName("apple")
.setColor("red")
.setFirmness("crunchy")
.build();比较这两个维基百科页面上的代码示例可能是值得的：
http://en.wikipedia.org/wiki/Factory_method_pattern
http://en.wikipedia.org/wiki/Builder_pattern
几乎可以将 Factory 模式视为 Builder 模式的简化版本。
在工厂模式中，工厂负责根据需要创建对象的各种子类型。
工厂方法的用户不需要知道该对象的确切子类型。工厂方法createCar的示例可能返回Ford或Honda类型的对象。
在Builder模式中，还可以通过 builder 方法创建不同的子类型，但是在同一子类中对象的组成可能有所不同。
要继续车子例如，你可能有一个createCar它创建了一个构建器方法Honda采用了 4 缸发动机 - typed 对象，或Honda -typed 对象有 6 个缸。构建器模式允许这种更精细的粒度。
Wikipedia 上提供了Builder 模式和Factory 方法模式的图表。