英文名BUILDER
用于将一个复杂对象与它的表示分离。使得同样的创建过程可以创建不同的表示。
假设现在要将一个RTF文档转换为word或者PDF。RTF rich text format富文本。
一般情况下我会定义一个方法RTFUtil.rtf2word和RTFUtil.rtf2pdf直接去转换就可以了。
在书中认为这个转化过程是一个比较复杂的过程,那么需要将转换字符串和转换pdf中的图片,链接等用不同的方法去表示,而且每一个转换都定义一个单独的类,而不是作为RTFUtil的一个方法。
UML图如下:
这里RTFReader是一个读取类,成员属性builder是Converter接口,Converter有两个实现类,分别是word转化器和PDF转化器。
当RTF需要转换成不同的目标格式的时候,只需要修改Converter实现类即可。
public static void main(String[] args){
Converter converter = new WordConverter();
//Converter converter = new PDFConverter();
RTFReader rtfReader = new RTFReader(converter);
rtfReader.parseRTF();
}
抽象出来的一般类图如下
这里Director起到的是调度的作用,他将需要组合的最终的各个部分调度起来,而各个部分的处理由Builder去处理。
这样通过彼此解耦有了更好的处理。
但是这里我有了一些小疑问,既然目标部分可以多样化,为什么源不能多样化。
如可以是pdf2word,也可以是rtf2word,word2pdf。
在源和目标之间加一个中间处理,将源的数据分析成目标可以处理的数据,然后组装成一个产品。
这个设计模式应该在销售中的产品订单组装成不同大对象有用。
构造器模式对构造过程把握的更精细,因为每一步是逐步组装的。