设计模式：真正的建造者模式

又臭又长的set方法

经常进行Java项目开发使用各类starter的你一定见过这种代码：

public class SwaggerConfig {@Beanpublic Docket api() {return new Docket(DocumentationType.SWAGGER_2).select().apis(RequestHandlerSelectors.any()).paths(PathSelectors.any()).build();}
}

相比较你的实体类的set方法，就感觉自己的set直观上就非常的low，十分不优雅，当然这里并不是指实体类，而是类似于一些接口调用时的参数dto对象的构造，在业务代码中构建参数实体十分的麻烦，例如：

@Data
public class DevParam {private Long id;private String filter;private String type;private int pageNo;private int pageSize;
}public class HttpUtil {private final static URL = "http://127.0.0.1:8080/deviceserver/search"public static JSONObject searchDeviceData(DevParam param) {HttpClient client = HttpClient.newHttpClient();HttpRequest request = new HttpRequest();request.uri(URL);request.body(JSONUtil.parseObj(param))//……其他http调用，组装返回数据逻辑、省略return XXX  }
}public class Test{public static void main(String[] args) {//需要调用接口获取数据DevParam param = new DevParam();param.setFilter("关键字");param.setPageNo(1);param.setPageSize(10);JSONObject retData = HttpUtil.searchDeviceData(param);JSONArray array = retData.getJSONArray("data");for(int i=0; i < array.size();i++){//……其他逻辑XXX}}}

而如果写成这样，逼格就会高很多

public class Test{public static void main(String[] args) {//需要调用接口获取数据JSONObject retData = HttpUtil.searchDeviceData(new DevParam().filter("XXXX")  .pageNo(1).pageSize(10));JSONArray array = retData.getJSONArray("data");for(int i=0; i < array.size();i++){//……其他逻辑XXX}}}

实体类的改进：简易版的Builder模式

而上述的DevParam的实现大家应该一眼就能看出来，即将原本void的set方法修改一下就可以满足装X的条件：

public class DevParam {private Long id;private String filter;private String type;private int pageNo;private int pageSize;public DevParam() {}public DevParam setId(Long id) {this.id = id;return this;}public DevParam setFilter(String filter) {this.filter = filter;return this;}public DevParam setType(String type) {this.type = type;return this;}public DevParam setPageNo(int pageNo) {this.pageNo = pageNo;return this;}public DevParam setPageSize(int pageSize) {this.pageSize = pageSize;return this;}}

实体类的改进：基于内部类的Builder实现

如果想看起来跟一开始的swgger的配置类一样高级，则可以使用内部静态类的方式实现该方法，即类内创建一个内部类，通过内部类创建外部类的实体对象。

public class DevParam {private Long id;private String filter;private String type;private int pageNo;private int pageSize;private DevParam() {}//省略此处的get和set方法public static class Builder {private Long id;private String filter;private String type;private int pageNo;private int pageSize;public Builder setId(Long id) {this.id = id;return this;}public Builder setFilter(String filter) {this.filter = filter;return this;}public Builder setType(String type) {this.type = type;return this;}public Builder setPageNo(int pageNo) {this.pageNo = pageNo;return this;}public Builder setPageSize(int pageSize) {this.pageSize = pageSize;return this;}public DevParam build() {DevParam devParam = new DevParam();devParam.id = this.id;devParam.filter = this.filter;devParam.type = this.type;devParam.pageNo = this.pageNo;devParam.pageSize = this.pageSize;return devParam;}}
}public class Test {public static void main(String[] args) {DevParam devParam = new DevParam.Builder().setId(1L).setFilter("filterValue").setType("typeValue").setPageNo(1).setPageSize(10).build();System.out.println(devParam);}
}

该种实现即是我们常用一些配置类、链接类创建时带build小尾巴的方式。

真正意义的建造者模式

其实虽然上述的DevParam类在构建时携带build，但是其实不是真正意义上的建造者模式（Builder），只能说是裁剪版的。建造者模式属于创建型模式，也就生成器模式，其核心思想是：

将复杂对象的构建和表示分离，使同样的构建过程可以创建不同的表示

建造者模式的结构

Builder:生成器接口，定义创建一个产品(Product)对象所需的各个部件的操作。

Concrete Builder:具体的生成器实现，实现各个部件的创建，并负责组装产品对象的各个部件，同时还提供一个让用户获取组装完成后的产品对象的方法。

Director:指导者，也被称为导向者，主要用来使用Builder(Builder)接口，以一个统一的过程来构建所需要的Product(Product)对象。

Product:产品，表示被生成器构建的复杂对象，包含多个部件。

样例代码：

class Product {private Long id;private String filter;private String type;private int pageNo;private int pageSize;public Product(Long id, String filter, String type, int pageNo, int pageSize) {this.id = id;this.filter = filter;this.type = type;this.pageNo = pageNo;this.pageSize = pageSize;}public Long getId() {return id;}public String getFilter() {return filter;}public String getType() {return type;}public int getPageNo() {return pageNo;}public int getPageSize() {return pageSize;}
}// 构建者接口
interface Builder {void setId(Long id);void setFilter(String filter);void setType(String type);void setPageNo(int pageNo);void setPageSize(int pageSize);Product getResultProduct();
}// 具体构建者
class ConcreteBuilder implements Builder {private Long id;private String filter;private String type;private int pageNo;private int pageSize;@Overridepublic void setId(Long id) {this.id = id;}@Overridepublic void setFilter(String filter) {this.filter = filter;}@Overridepublic void setType(String type) {this.type = type;}@Overridepublic void setPageNo(int pageNo) {this.pageNo = pageNo;}@Overridepublic void setPageSize(int pageSize) {this.pageSize = pageSize;}@Overridepublic Product getResultProduct() {return new Product(id, filter, type, pageNo, pageSize);}
}// 指挥者
class Director {private Builder builder;public Director(Builder builder) {this.builder = builder;}public void construct() {builder.setId(1L);builder.setFilter("filterValue");builder.setType("typeValue");builder.setPageNo(1);builder.setPageSize(10);}public Product getResultProduct() {return builder.getResultProduct();}
}public class Main {public static void main(String[] args) {Director director = new Director(new ConcreteBuilder());director.construct();Product product = director.getResultProduct();System.out.println(product);}
}

一个建造者经典案例

可能仅看上述建造者的demo代码，发现还不如简易版或者内部类版本的创建者，甚至都不如单纯的实体类set省事，但是先别急，我们带入一个实际的场景来看，以一个导出数据的案例来看，在做导出功能时，通常需要支持导出不同格式的数据文件，以此来做一个文件导出框架，通常对于导出框架，需要对导出内容和格式进行一个整体的约束：

导出的文件，不管什么格式，都分成3个部分，分别是文件头、文件体和文件尾。
在文件头部分，需要描述如下信息:分公司或门市点编号、导出数据的日期，对于文本格式，中间用逗号分隔。
在文件体部分，需要描述如下信息:表名称，然后分条描述数据。对于文本格式，表名称单独占一行，数据描述一行算一条数据，字段间用逗号分隔。
在文件尾部分，需要描述如下信息:输出人。

下面对以上需求基于建造者进行设计类图：

具体代码实现：

// 抽象构建者接口
interface Builder {void buildHeader();void buildBody();void buildFooter();StringBuffer getResult();
}// 具体构建者：XML格式
class XmlBuilder implements Builder {private StringBuffer buffer;public XmlBuilder() {this.buffer = new StringBuffer();}@Overridepublic void buildHeader() {buffer.append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n");buffer.append("<document>\n");}@Overridepublic void buildBody() {buffer.append("    <body>\n");buffer.append("        <content>Example content</content>\n");buffer.append("    </body>\n");}@Overridepublic void buildFooter() {buffer.append("</document>\n");}@Overridepublic StringBuffer getResult() {return buffer;}
}// 具体构建者：TXT格式
class TxtBuilder implements Builder {private StringBuffer buffer;public TxtBuilder() {this.buffer = new StringBuffer();}@Overridepublic void buildHeader() {buffer.append("Document Content:\n");}@Overridepublic void buildBody() {buffer.append("Example content\n");}@Overridepublic void buildFooter() {buffer.append("End of Document\n");}@Overridepublic StringBuffer getResult() {return buffer;}
}// 指挥者
class Director {private Builder builder;public Director(Builder builder) {this.builder = builder;}public void construct() {builder.buildHeader();builder.buildBody();builder.buildFooter();}public StringBuffer getResult() {return builder.getResult();}
}// 客户端使用示例
public class BuilderPatternDemo {public static void main(String[] args) {Director director;// 创建XML格式的构建者director = new Director(new XmlBuilder());director.construct();System.out.println("XML Format:\n" + director.getResult());// 创建TXT格式的构建者director = new Director(new TxtBuilder());director.construct();System.out.println("TXT Format:\n" + director.getResult());}
}

首先通过builder定义了构建文档所需的方法buildHeader, buildBody, buildFooter 和 getResult，以两个类分别根据构建的文件特征实现了Builder接口；最后通过指导者使用Builder来构建文档，并在构建完成后获取最终的文档内容。

建造者模式的理解

建造者模式的主要功能是构建复杂的产品，而且是细化的、分步骤的构建产品，也就是建造者模式重在一步一步解决构造复杂对象的问题。如果仅仅这么认识建造者模式的功能是不够的。更为重要的是，这个构建的过程是统一的、固定不变的，变化的部分放到生成器部分了，只要配置不同的生成器，那么同样的构建过程，就能构建出不同的产品来。

再直白点说，建造者模式的重心在于分离构建算法和具体的构造实现，从而使得构建算法可以重用。具体的构造实现可以很方便地扩展和切换，从而可以灵活地组合来构造出不同的产品对象。

建造者模式的构成

要特别注意，建造者模式分成两个很重要的部分。

一个部分是 Builder 接口，这里是定义了如何构建各个部件，也就是知道每个部件功能如何实现，以及如何装配这些部件到产品中去;
另外一个部分是 Director，Director 是知道如何组合来构建产品，也就是说Director负责整体的构建算法，而且通常是分步骤地来执行。

不管如何变化,Builder 模式都存在这么两个部分,一个部分是部件构造和产品装配,另一个部分是整体构建的算法。认识这点是很重要的，因为在生成器模式中，强调的是固定整体构建的算法，而灵活扩展和切换部件的具体构造和产品装配的方式，所以要严格区分这两个部分。

在指导者（Director）实现整体构建算法时，遇到需要创建和组合的具体部件的时候，就会把这些功能通过委托，交给Builder去完成。

建造者模式的本质

建造者模式的本质是分离整体构建算法和部件构造。构建一个复杂的对象，本来就有构建的过程，以及构建过程中具体的实现。建造者模式就是用来分离这两个部分，从而使得程序结构更松散、扩展更容易、复用性更好，同时也会使得代码更清晰，意图更明确。
虽然在建造者模式的整体构建算法中，会一步一步引导Builder来构建对象，但这并不是说生成器主要就是用来实现分步骤构建对象的。建造者模式的重心还是在于分离整体构建算法和部件构造，而分步骤构建对象不过是整体构建算法的一个简单表现，或者说是一个附带产物。