可扩展性的builder模式的构建方法

http://www.cnblogs.com/happyhippy/archive/2010/09/01/1814287.html

使用builder模式的时候：

本篇文章的原因：builder模式接口非常固定，不允许改变。

当有新产品创建任务的时候。首先是想着通过参数来控制产品的变化，这样可以直接复用现有的实现。如果现有的实现无法满足需求，就需要重新实现一个concreatebuilder来满足新的需求。但是需求又是不可预见的，如何防止系统能够应对不断变化的客户需求呢？

面向业务的复杂产品一开始就知道需求基本上是不可能，特别是对于客户级别的产品来说。因此builder模式只适合建造一些与业务相关性不大的产品。例如StringBuilder，SQLInsertBuilder，AlertDialogBuilder。这些builder的共同点是，在整个系统中的功能基本上都是定死的，不需要改变的。改变的只有组装过程和组成部分。像StringBuilder，不同的组装过程可能会产生不同的结果，而AlertDialogBuilder是不同的组成部分产生的不同结果。

2.但是，如果说，非要使用客户级别的builder模式。那么下面的建议将是比较有用的：

2.1.不到万不得已不要建立builder的子类。

2.2.使用装饰者模式防止builder子类的膨胀。

2.3.参数化builder模式，保证builder的可扩展性。

2.4.用抽象工厂模式来配置系统。