Builder模式

学习rabbitmq，在看其java client api文档时，讲到AMQP类的请求、应答描述符都有builder类，符合Builder模式，让创建协议对象更加简单，允许使用不变的状态创建他们。

 

一直没有系统学习设计模式，从网上查了一下Builder模式的讲解，中文资料中讲builder模式的基本是人云亦云，拿着翻译的半通不通的所谓中文标准定义，按照自己的例子理解一番，然后写一个简单的小例子，算是搞定。看到那些为了模式而模式的别扭代码，根本看不出builder模式到底有什么好的。

 

这些例子一般是这样的，定义一个Director类，定义一个Builder接口。其中Builder接口有几个createPart1()、createPart2()这样的方法，最后必定有一个getResult()方法返回一个Product对象。而Director类呢，构造时传进一个Builder接口，然后有一个construct方法，里面依次调用builder接口的那几个create方法完事。

 

builder模式根本就不是为这些创建过程很简单的例子准备的，这些例子代码使用builder模式有点“为赋新词强说愁”的感觉，怎么看怎么别扭。看这些例子的用意，是想把对象的创建过程提取到一个叫做Director的类里，这样做有几个前提，才能保证这种提取有意义：

 

1. 创建过程比较普适，有多种Product的创建过程都是一模一样的。

 

2. 创建过程比较复杂，有特殊的顺序和逻辑要求，或者是有非常复杂的参数列表，否则如果就是一两行简单代码，抽象出来没有意义。

 

这些例子中，基本都不满足这两个前提，比如有个配套餐的例子，说套餐A是xxx，套餐B是yyy，可以建立两个Builder，分别生产套餐需要的各种配菜，另外建一个Director类调用Builder中相应的方法生成套餐。这不是完全多余的吗？Director中的过程根本不能通用，谁规定两个套餐必须使用同样的方式创建的？

 

在AMQP.BasicProperties.Builder.build()方法中，封装了对BasicProperties构造函数的调用。这个调用非常复杂，有14个参数：

 

            public BasicProperties build()
            {
                return new BasicProperties(contentType, contentEncoding, headers, deliveryMode, priority, correlationId, replyTo, expiration, messageId, timestamp, type, userId, appId, clusterId);
            }

 

这个封装是比较有意义的。而是用这种方式的主要原因是，builder的所有其他方法都是给自己设置属性，这样可以在任何时刻调用build把自己的一份拷贝生成为BasicProperties。