java的设计模式 - Builder模式
Builder 模式的目的？
构造对象的方式过于复杂，不如将之抽离出来。比如,构造器参数过多
这样说也有点抽象，举个例子吧。
举个例子
比如 非常热门的消息队列RabbitMQ 的 AMQP.BasicProperties
因为它的属性比较多，所以构造函数也是挺吓人的。
我看到也不太想调用。
如果现在要构造一条消息
- 投递模式（delivery mode）为 2
- 优先级（priority）是 2
- content-type 为 text/plain
在没有 builder 模式之前，是这样构造的
new AMQP.BasicProperties("text/plain",null,null,2,1,null,null,null,null,null,null,null,null,null);
痛苦啊！！！不信，你自己也可以尝试构造一下。
- 构造函数有很多你不想设置的参数
- 你要看准，哪个参数要赋值，哪个参数不赋值，一不小心就可能出错了。而这里有 14 个参数。。。
- 维护性差，写完代码再看一下，也看不出这个参数究竟是什么意思。还要点进去，一个一个参数地看才知道是什么意思
而用了 Builder 模式后。
new AMQP.BasicProperties.Builder()
.contentType("text/plain")
.deliveryMode(2)
.priority(1)
.build();
舒畅！！！
Builder 是如何实现？
很简单。
- 在
BasicProperties中添加一个叫Builder的内部类 - Builder 中所有字段和
BasicProperties类是完全一致的 - 而
Builder实例在调用build函数的时候，再调用BasicProperties的构造函数构造对象。
代码如下
public static class BasicProperties{
private String contentType;
private String contentEncoding;
private Map<String,Object> headers;
private Integer deliveryMode;
private Integer priority;
//... 还有很多属性
public BasicProperties(
String contentType,
String contentEncoding,
Map<String,Object> headers,
Integer deliveryMode,
//...
String clusterId){
this.contentType = contentTypel;
this.contentEncoding = contentEncoding;
//...
}
public static final class Builder {
private String contentEncoding;
private Map<String,Object> headers;
private Integer deliveryMode;
private Integer priority;
//.. 和BasicProperties的字段一致的。
public Builder contentType(String contentType){
this.contentType = contentType;
return this;
}
public Builder contentEncoding(String contentEncoding){
this.contentEncoding = contentEncoding;
return this;
}
public BasicProperties build() {
return new BasicProperties
( contentType
contentEncoding,
//还有很多属性
);
}
}
}
分析
Builder 模式的好处
- 不用花太多心思去记构造器的顺序，在 ide 中输入一个点就有自动提示了
- 好维护，很容易看到看明白这是什么属性
坏处
- 构造对象就要先调用 Buidler 构造器，多了构造器的开销
- 类的关系变得复杂了
其他的做法
如果不用 Builder 模式，有其他的做法吗？
重叠构造器？
比如，上面的例子，我构造的消息只需 投递模式（delivery mode）、优先级（priority）、 content-type ，专门为这几个参数弄个专门的构造函数，可以吗？
调用就变成这样了。
new AMQP.BasicProperties("text/plain",2,1)
可以，
- 但依然不太好看。
- 如果有不同的需求，各种属性都排列组合一下也麻烦。
- 不实际，因为类字段的类型可能会是一样的，有些组合注定不行
javaBean 模式呢?
BasicProperties p = new AMQP.BasicProperties();
p.setContentType("text/plain");
p.setDeliveryMode(2);
p.setPriority(1);
在《effective java》中就探讨过这个可能，书中是这样说的
因为构造过程被分到几个调用中，在构造过程中 javaBean 可能处于不一致的状态。类无法仅仅通过检验构造器参数的有效性来保证一致性。试图使用处于不一致状态的对象，将导致失败，这种失败与包含错误的代码大相径庭，因此它调试起来十分困难。与此相关的另一点不足在于，javaBeans 模式阻止了把类做成不可变的可能，这需要程序员付出格外的努力来确保它的线程安全。
这话就有点摸不着头脑，什么意思
其实意思是大概的，
- javaBean 是构造与字段赋值分离的，有可能 线程 1 在给对象 Obj 赋值，还没有赋完成的时候，线程 2 就拿了 Obj 的值了，就不一致了
- 如果 Obj 的字段全都是 final 的，不会出现上面那种情况，但字段只能会通过构造函数赋值（builder 模式也行），不能使用 javaBeans 的 setXXX 函数赋值了。
- 对多线程要求的，比如是传给消息队列的对象，程序员要保证下线程安全。
- 这也是个一个开放开闭的问题，Javabean 这样的写法确实和完全开放没啥区别，如果字段确定下来不用改了就最好设为 final 。
以上
