使用Google calendar v3 API的时候，大量发现Builder使用。比如Credential类，查了查Builder模式的讲解，始终感觉代码的实现和标准定义不太相同。最后发现这种实现方式是《Effective java 2nd》中的一种实现(Item 2: Consider a builder when faced with many constructor parameters)。静态工厂和构造器都有一个通病：对于存在大量可选构造参数的对象，扩展性不好。经典的解决方案是提供多个构造函数，第一个构造函数只有必须的参数，第二个构造函数除了必须参数还有一个可选参数，第三个除了必须参数还有两个可选参数。。。这样下去知道最后一个可选参数出现（
telescoping constructor）。这种方案的问题是，当构建对象的时候很容易把其中两个参数的位置放反。。。。
（难发现的bug）。
另一种解决方案是JavaBean 模式，先调用无参构造函数再调用各个set方法来组装对象。这种方案的问题是不能强制一致性。如果没有set某些必须的参数的话，对象可能处于不一致（
inconsistent）的状态（难发现的bug）。另外一个缺点是JavaBean模式不能让类immutable，需要程序员额外工作保证线程安全。
第三种方式就是Builder设计模式。这种方式混合了
telescoping constructor模式的安全性和JavaBean模式的可读性。客户端调用有所有必填参数的构造器（或静态工厂），得到一个builder对象。然后调用builder对象的方法去set各个选填参数。最后调用无参的build方法产生一个immutable的对象实例。immutable对象有非常多优点而且可能很有用。builder的set方法都是返回builder本身，所以调用也是可以chained。如：
GoogleCredential credentialNew = new GoogleCredential.Builder().setTransport(HTTP_TRANSPORT)
.setJsonFactory(JSON_FACTORY).setClientSecrets(clientSecrets)
.addRefreshListener(new CredentialStoreRefreshListener(userID, new DBCredentialStore())).build()
.setAccessToken(accessToken).setRefreshToken(refreshToken)
客户端代码很好写，更重要的是易读。Builder模式模拟了在Ada和Python语言里的命名可选参数（
named optional parameters）。
同时Builder类设置为static也是对Item 22：Favor static member classes over nonstatic的实践