创建——构造器模式

英文名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。

在源和目标之间加一个中间处理，将源的数据分析成目标可以处理的数据，然后组装成一个产品。

这个设计模式应该在销售中的产品订单组装成不同大对象有用。

构造器模式对构造过程把握的更精细，因为每一步是逐步组装的。