Refactoring to Patterns 读书笔记（六）

前一阵公司的事情繁忙，导致这 Refactoring to Patterns 的书看完许久，却没有时间提笔来写这篇读书笔记。现在有点时间，总算是可以继续了。

应用 Composite 模式替换隐式树结构

在处理数据的程序（例如，生成 XML 文档）中，我们常常会隐式地实现一些树状结构的程序，就像下图左边所显示的那样子：



在这种情况下，构建隐式树的代码和展现隐式树的代码紧密地耦合在一起（不同功能的代码之间存在高耦合！）。或者是条件逻辑判断的代码堆叠在一起，也能够构成一棵隐式树。
虽然两种隐式树在其本质上是不同的，但是都可以用 Composite 模式来解决。一般来说，对于第一种情况，使用 Composite 模式将可以把负责构建树的代码和负责展现树的代码分离开来。在应用了 Composite 模式进行重构之后，我们会发现这时客户代码和 Composite 代码之间又产生了不必要的高耦合情况，如果有需要继续重构的话，则可 应用 Builder 模式封装 Composite 模式。
应用 Composite 模式替换隐式树的好处有：

• 将诸如格式化、增加节点、删除节点之类的重复指令代码封装起来。
• 提供了处理相似逻辑代码增殖的通用方法。
• 简化了客户端代码的构建对象（例如 XML 节点）的责任。

应用 Builder 模式封装 Composite 模式

在前面一节中提到可以应用 Builder 模式来封装 Composite 模式，因为 Composite 的构建过程往往是重复性的、复杂的、易滋生错误的。而使用 Builder 模式则可以将构建 Composite 的过程封装起来，这样客户代码只需要调用 Builder 中的创建方法来构造 Composite，而不需关心其是如何被创建的。
Builder 模式的另外一个用途是将复杂对象的内部表现形式与起构建过程分离开来。也就是说，我们可以用 Builder 模式为其所封装的 Composite 或者复杂对象创建出不同的表现形式。
下面是书中的例图：