程序员就相当于建造模式类图当中的Director,他的意图决定了自定义控件如何实现.例如我想做一个自定义的分面导航控件,Control类相当于Builder,它负责指引具体的生产者类(ConcreteBuilder)如果完成Director的意图.具体的生产者当然就ConcreteBuilder了,它按照Control类的指示来完成控件具体的创建过程.
这样的程序在建造者模式中并不是标准的,它省略了抽象建造者角色及Director类.
看来有时候你不想用模式都难,使用模式应该是一种顺其自然的现象,设计模式它是用来解决问题的,并不是让我们强行用它(强扭的瓜不甜)，否则会因为过度的设计给原本简单的系统带来维护上的困难。
上面的分页控件代码中可以看出，所谓建造者模式，它内容结构比较复杂，往往会包含非常多的方法等，但从整体上来说，创建过程相对稳定，但是它的内部成员不稳定。每个控件都具备相同的生命同期，从初始化到呈现到最后的销毁，但其中的实现过程又是不同的。
针对这种情况就可以把相对复杂的创建过程抽象出来，让创建过程与实现过程分离，从而达到相同的创建过程可以实现
不同的表现方式的目的.
创建者模式的特点:
1:最终创建的产品(Product)内部结构相对复杂
2:Product的创建过程稳定.
3:Product的内部对象的实现过程是可变动的。
4:Product并不关心内部子系统如何实现(只求结果不关心过程).
5:Product的创建过程与实现部分分离。
6:同样的创建过程可以实现不同的表现结果.
适用性：
没有唯一的标准,如果开发者感觉自己的项目适合创建者模式的特点，那么你就可以尝试去用，否则还是少用。
总结:
设计模式离我们并不远,其实就在我们身边,就看你有没有心去关注它的存在了. 一个善于应用OO的程序员总会有机会把设计模式当成解决问题最好的武器
相关文章：