建造者模式
Builder在Java中一种简化的使用方式
当一个类的构造函数参数个数超过4个，而且这些参数有些是可选的参数，考虑使用构造者模式。
当一个类的构造函数参数超过4个，而且这些参数有些是可选的时，我们通常有两种办法来构建它的对象。 例如我们现在有如下一个类计算机类Computer，其中cpu与ram是必填参数，而其他3个是可选参数，那么我们如何构造这个类的实例呢,
以前，通常有两种常用的方式：
public class Computer {
private String cpu;//必须
private String ram;//必须
private int usbCount;//可选
private String keyboard;//可选
private String display;//可选
}
第一：折叠构造函数模式（telescoping constructor pattern ），这个我们经常用,如下代码所示
public class Computer {
...
public Computer(String cpu, String ram) {
this(cpu, ram, 0);
}
public Computer(String cpu, String ram, int usbCount) {
this(cpu, ram, usbCount, "罗技键盘");
}
public Computer(String cpu, String ram, int usbCount, String keyboard) {
this(cpu, ram, usbCount, keyboard, "三星显示器");
}
public Computer(String cpu, String ram, int usbCount, String keyboard, String display) {
this.cpu = cpu;
this.ram = ram;
this.usbCount = usbCount;
this.keyboard = keyboard;
this.display = display;
}
}
第二种：Javabean 模式，如下所示
public class Computer {
...
public String getCpu() {
return cpu;
}
public void setCpu(String cpu) {
this.cpu = cpu;
}
public String getRam() {
return ram;
}
public void setRam(String ram) {
this.ram = ram;
}
public int getUsbCount() {
return usbCount;
}
...
}
那么这两种方式有什么弊端呢？
第一种主要是使用及阅读不方便。你可以想象一下，当你要调用一个类的构造函数时，你首先要决定使用哪一个，然后里面又是一堆参数，如果这些参数的类型很多又都一样，你还要搞清楚这些参数的含义，很容易就传混了。。。那酸爽谁用谁知道。
第二种方式在构建过程中对象的状态容易发生变化，造成错误。因为那个类中的属性是分步设置的，所以就容易出错。
为了解决这两个痛点，builder模式就横空出世了。
如何实现
1. 在Computer 中创建一个静态内部类 Builder，然后将Computer 中的参数都复制到Builder类中。
2. 在Computer中创建一个private的构造函数，参数为Builder类型
3. 在Builder中创建一个public的构造函数，参数为Computer中必填的那些参数，cpu 和ram。
4. 在Builder中创建设置函数，对Computer中那些可选参数进行赋值，返回值为Builder类型的实例
5. 在Builder中创建一个build()方法，在其中构建Computer的实例并返回
package com.example.designpatterns.builder;
public class Computer {
private String cpu;//必须
private String ram;//必须
private int usbCount;//可选
private String keyboard;//可选
private String display;//可选
//省略get,set方法
private Computer(Builder builder) {
this.cpu = builder.cpu;
this.ram = builder.ram;
this.usbCount = builder.usbCount;
this.keyboard = builder.keyboard;
this.display = builder.display;
}
public static class Builder{
private String cpu;//必须
private String ram;//必须
private int usbCount;//可选
private String keyboard;//可选
private String display;//可选
public Builder(String cpu, String ram) {
this.cpu = cpu;
this.ram = ram;
}
public Builder setUsbCount(int usbCount) {
this.usbCount = usbCount;
return this;
}
public Builder setKeyboard(String keyboard) {
this.keyboard = keyboard;
return this;
}
public Builder setDisplay(String display) {
this.display = display;
return this;
}
public Computer build(){
return new Computer(this);
}
}
//在客户端使用链式调用，一步一步的把对象构建出来。
public static void main(String[] args) {
Computer computer = new Computer.Builder("","")
.setDisplay("")
.setKeyboard("")
.setUsbCount(0)
.build();
}
}
其实上面的内容是Builder在Java中一种简化的使用方式，经典的Builder 模式与其有一定的不同
经典Builder中 包含以下几个角色：
1. Builder(抽象建造者): 是一个抽象接口，为了创建一个产品对象的各个部件 ，主要有两类方法，一类是buildXX,用于创建复杂对象的各个部件，一类是getProduct，用于返回复杂对象。
2. ActualBuilder(实际的建造者)：实现Builder接口，实现各个部件的建造方法，返回创建好的复杂对象。
3. Product(产品角色)：被构建出来的复杂对象，包含多个部件。
4. Director(指挥者):负责安排部件创建的顺序，客户端一般只和指挥者进行交互，在客户端确定实际的建造者，然后通过指挥者的构造函数或者setter方法将该对象传入到指挥者类中。
抽象建造者
package com.example.designpatterns.builder;
/**
* Builder(抽象建造者)
* 是一个抽象接口，为了创建一个产品对象的各个部件 ，主要有两类方法，一类是buildXX,用于创建复杂对象的各个部件，一类是getProduct，用于返回复杂对象。
*/
public abstract class Builder {
//创建产品对象
protected Product product = new Product();
//具体不加建造过程在ActualBuilder中实现
public abstract Builder buildPartA();
public abstract Builder buildPartB();
public abstract Builder buildPartC();
//定义一个钩子方法，是否需要设置partC
public boolean isPartC(){
return true;
}
//定义工厂方法，返回完整产品对象
public Product getProduct(){
return product;
}
}
实际的建造者
/**
* 实际的建造者1
* 实现Builder接口，实现各个部件的建造方法，返回创建好的复杂对象
*/
public class ActualBuilder1 extends Builder {
@Override
public Builder buildPartA() {
product.setPartA("设置A部分");
return this;
}
@Override
public Builder buildPartB() {
product.setPartB("设置B部分");
return this;
}
@Override
public Builder buildPartC() {
product.setPartC("设置C部分");
return this;
}
@Override
public boolean isPartC() {
return false;
}
}
/**
* 实际的建造者2
* 实现Builder接口，实现各个部件的建造方法，返回创建好的复杂对象
*/
public class ActualBuilder2 extends Builder {
@Override
public Builder buildPartA() {
product.setPartA("设置A部分");
return this;
}
@Override
public Builder buildPartB() {
product.setPartB("设置B部分");
return this;
}
@Override
public Builder buildPartC() {
product.setPartC("设置C部分");
return this;
}
@Override
public boolean isPartC() {
return true;
}
}
Product(产品角色)
package com.example.designpatterns.builder;
/**
* Product(产品角色)
*/
public class Product {
//定义部件
private String partA;
private String partB;
private String partC;
public String getPartA() {
return partA;
}
public void setPartA(String partA) {
this.partA = partA;
}
public String getPartB() {
return partB;
}
public void setPartB(String partB) {
this.partB = partB;
}
public String getPartC() {
return partC;
}
public void setPartC(String partC) {
this.partC = partC;
}
}
指挥者Director
package com.example.designpatterns.builder;
/**
* 指挥者
*/
public class Director {
//构造复杂产品对象
public Product construct(Builder builder;){
//指挥者可以决定产品不见的构建顺序
builder.buildPartA()
.buildPartB();
//钩子方法 用来取到是否需要构建某个部件
if (builder.isPartC()){
//表示需要才会构建
builder.buildPartC();
}
return builder.getProduct();
}
}
可以看到，文章最开始的使用方式是传统builder模式的变种， 首先其省略了director 这个角色，将构建算法交给了client端，其次将builder 写到了要构建的产品类里面，最后采用了链式调用。
建造者模式总结
优点
1. 客户端不需要知道具体创建对象的细节，将产品本身和产品的创建过程解耦，相同的创建过程可以创建出不同的产品对象。
2. 每个具体建造者相对独立，增加新的具体建造者不会影响现有的类库代码，符合开闭原则。
3. 可以采用钩子方法精确的控制某个具体建造者是否需要某个部件。可以针对的控制产品构建流程。
缺点
如果产品之间的差异性较大，那么即使使用钩子方法来控制，那也是极其麻烦，且公共接口很难抽象。非常不适合。
适用场景
1. 需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性。
2. 需要生成的产品对象的属性相互依赖，需要指定其生成顺序。
3. 对象的创建过程独立于创建该对象的类。在建造者模式中通过引入了指挥者类，将创建过程封装在指挥者类中，而不在建造者类和客户类中。
4. 隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。
参考文章：
https://zhuanlan.zhihu.com/p/58093669
https://www.cnblogs.com/1314xf/p/10150533.html
344
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
