Builder模式是设计模式中比较少争议的一个，其实也是比较有内容的一种。

我们先来看Builder模式的结构，它由四个部分组成：Director , Builder , Builder实现类，Product类。Part作为Product内部的概念被隐藏了。它的设计初衷是将复杂对象的构成（也就是部件）和构建逻辑（也就是算法或者说处理顺序）分离开来。换成现实中最简单的例子，一堆积木玩具，按照图纸，可以堆砌不同的的建筑。其中积木就相当于Part，图纸相当于Director，而建筑就是Product了。当然，这样的例子还是会让人有些糊涂，比如说什么是Builder的实现呢？实际上在这个例子中，积木已经是形成的单元了，它就是Builder的产物而已。

面对这样一个看似简单的模式，初学者又会有这样的疑问，我们使用Builder的目的究竟是想返回不同的实例（都是Product的一种实现）还是根据返回另外的某种实例（只是某些Part没有builder）呢？让我们看看《设计模式：可复用面向对象软件的基础》一书中举的例子，书中Builder的三个实现类ASCIIConvertor , TexConverter 和TextWidgetConverter有各自的getResult的方法（getASCIIText, getTexText, getTextWidget），并且返回不同的类型。那么说明Builder返回的是后者，也就是另外的实例。

这时，我们又来对比一下Jdon网站板桥关于builder的举例，也就是关于汽车和汽车部件的例子（http://www.jdon.com/designpatterns/builder.htm），或者联想一下，在现实生活中，经常有这样的情况。比如说：一种汽车，有豪华版，舒适版，经济版等，都是一种产品，但是内部的部件搭配不同。那么他们是否又能使用Builder模式呢? 或者说，板桥所举的例子不是标准的Builder模式？

似乎不敢确定答案，好，我们再回头看看GOF关于builder模式的适用范围：

其实这两种范围也就是描述了Builder模式的两种应用场景。第一种也就是板桥所举的关于汽车的例子，同样一种builder实例，可以根据Director来获得同一产品不同的实现，它关注的是分离对象的构造算法和组成部分。而第二种也就是原书中的例子，不同的builder获得不同的产品，它关注的是被构造对象的不同。

 

这样一看，大家是否比较豁然开朗，对不同的Builder和Director关注度，会给我们带来不同的应用。而在绝大多数文章中，是没有提到这点的，或者说并没有清晰的谈到这点。

 

正因为有两种不同侧重点的应用，所以当对问题分析不够透彻时，或者对模式侧重点不明晰时，我们往往会使用了不太合适的实现。这样，也就会让人感到一些奇怪和误解，同时也限制了调用者的可扩展性。（我们往往重视模式结构单元的可扩展性，确又忽略了调用者的扩展性。）

 

 说起工厂模式，哈，几乎所有的开发人员都知道，但是，估计百分之八十以上的人用得比较滥（嘿嘿，注意哦，我用的是滥，而不是烂）。

 好吧，先简单介绍一下工厂模式。在GOF中，工厂模式有两种，工厂与抽象工厂，而实际上，有三种，也就是简单工厂。

 简单工厂一般由三种对象构成（工厂对象，抽象产品对象，具体产品对象），工厂模式一般由四种对象构成（工厂接口，产品抽象，具体工厂，具体产品），而抽象工厂则至少由7个以上对象了。（抽象工厂，两种以上不同的产品抽象对象，两种以上不同的工厂实现对象，两种以上不同的具体产品对象）。哈哈，复杂吧！来，我们用个很简单的实际生活中的例子来说明一下。简单工厂的例子是最常见的了，我们把抽象产品对象理解为一种产品，拿电脑来说事吧，945的主板就相当于抽象产品，ASUS就相当于简单工厂，为了针对不同的人群和需求，那么就可以偷工减料，也可以狠砸money，自然出来的产品就不同咯。对于使用者某种需要来说，关心的就是是否是945的板子，是否支持Intel的CPU。好，再让我们来看看工厂，DELL是发包商，它发现微星的板子比华硕的便宜一些，又同意是945的板子，那么它就会根据需要，调整不同的厂商来制作不同的板子，当然都是统一类型。这时候，朋友们可以发现了吧，简单工厂和工厂使用者上的不同，稍后再继续讨论这点。抽象工厂，神舟电脑公司就想贴牌，所以它要找些产品线丰富的厂商来生产，这样可以提高兼容性。好了，它需要一个抽象的工厂，这个工厂生产主板，显卡还有其他一些设备。但是呢，它经常需要根据实际的一些需要和条件来改变这个实际生产的厂商了。好了，华硕、微星接到了订单，他们担任实际的工厂了，产品嘛，就是显卡和主板，当然，两个厂商会根据需要生产出自己独特的产品，尽管型号一样。我们把角色对上位，大家可以一目了然了吧。

这里我们就带来了设计模式的一个重要的概念，既然面向对象是生活的抽象，事物都可以以对象描述，那么作为一种解决方案的模式，它就肯定表明了生活中常见的例子。那么好，为什么要用模式，哪些地方可以用这个模式。我们看看生活中的情况，也就一清二楚了。

我们可以看出，三种工厂模式使用的区别在于使用者上，使用者有不同的需求，那么就会需要调整相应的结构。在我们实际工作中，很多时候，实例对象的构造比较简单，所以很多时候简单工厂的应用比较广泛。但是，被滥用的也是它了。为什么呢，首先，我们需要了解为什么要使用它？其实这里有个隐含的概念，也就是单元。不知道朋友们是否发现，在每一个模式的图里只画出了内部的结构，而并没有画出调用者（最多也只是一个辅助的角色出现，只是为了说明调用的关系）。那么工厂模式运用的地方又是在哪里呢？根据前面的例子描述，我们可以看出，它是用在单元外部与单元内部的交互上了。这也就是所有创建模式的分类原因。我们这提这样一个问题，在单元内部是否可以使用工厂呢？单元又是一个多大的概念呢？我们说吧，在单元内部使用工厂（包括简单工厂）往往是种滥用，因为面向对象设计原则告诉我们，对象是可扩展，而不应被修改（也就是开闭原则）的。如果我们追求的是单元的复用，而不仅仅是某个类的复用，过多的使用工厂，只会是堆砌无用的代码而已。至于单元的大小又如何确定呢？想想你要复用的最小结构吧，那就是单元。好了，又会有朋友说，那如果不用工厂，我如果想改变一些实例，怎么办？嘿，我就告诉大家一个经典的设计，其实也就是在jdk实现中广泛运用的设计方式，Wrapper实现。 所有java的开发人员都非常清楚Map, Set , List ,这样的接口，在我们使用的时候，不会有哪位朋友去用工厂生产他们的实例吧？用的话，赶紧改哦。我们知道，常用的实现HashMap / HashSet / ArrayList都是可以修改的，线程不安全的。我们往往遇到一种尴尬，当我们返回List, Map , Set他们实例的时候很少考虑到他们也许会出现并发问题，他们也许会被别人修改内部的内容。怎么办？让我们看看Collections这个类吧， 在JDK1.4及以前的版本里，它提供了unmodified, synchronized的封装。传接口普通实例进去，返回接口的封装实例。对了，这就是非常经典的接口+（抽象类）+标准参考实现+封装实现。它就可以代替工厂在单元内部的使用者使用了。

那么好，在针对单元外部使用者来说，究竟是用工厂还是抽象工厂呢？他们的优缺点又在哪里呢？我们可以看看，对于工厂模式，一般必须由外部使用者指定它的工厂实例（变种的除外，到时候会讨论所谓变种的问题），当然对于内部实体来说，它可以供外部者更改或参考。对于在不考虑单元外部程序复用的情况下，它是不错的。而抽象工厂了，其实它的关注角度已经由产品移到了工厂上，同时它考虑了产品实例和工厂实例交叉的问题。换言之，其实就是将关系由一对多，变成了多对多。它的优点是提供了多种组合可能性。它存在的问题呢？想要增加一种产品的时候会发现它无法扩展了（这是很多人总结的一些问题，不过这个问题真的存在么？存在的话，那是不是就已经改变了抽象工厂模式应用的基础呢？离开了应用环境基础的话，又怎么回是抽象工厂模式本身的问题呢？） 一般来说，对于服务型对象的工厂，使用抽象工厂模式比较合适（有更好的扩展性）；而一般对于实体型对象的工厂呢，使用工厂模式就相对简单，也更加让人容易明了。

总结一下，世界上没有那种东西是放之四海皆准的真理，模式也一样。模式存在的本身是在某种环境下应用实践的总结，离开了对应的环境，所招来的骂名，我想它们也是会委屈滴…… 所以，朋友们，不要随便骂哪个模式如何烂，如何不好。不好的只是我们用滥了。