Composite模式

1 意图：将对象组成树形结构，以表示“部分——整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。

2 动机：同意处理图元对象和包含图元的容器对象。Composite通过递归的方式实现统一处理。

关键是一个抽象类，既能代表图元又能代表容器。

3 适用性：

. 表示"部分-整体"的层次结构

. 希望用户忽略组合对象和单个对象的不同，用户将统一使用组合结构中的所有对象。

4 参与者：

. Component（Graphic）

为组合中的对象声明接口。适当情况，实现所有类公有接口的缺省行为。声明一个接口用于访问和管理Component的子组件。

（可选）递归结构中定义一个接口，访问一个父部件，合适情况下实现它。

. leaf

表示叶节点对象，没有子节点。定义图元对象的行为。

. Composite

定义有子部件的那些部件的行为。存储子部件。在Component接口中实现与子部件有关的操作。

5 Client：通过Component接口操作组合部件的对象。

6 协作：使用Component类接口与组合结构中的对象交互。如果接收者是一个叶节点，直接处理请求。如果是Composite，转发给子部件。之前或之后加一些操作

7 效果：

Composite模式：

. 定义组合对象和基本对象

. 简化客户代码

. 使得更容易增加新类型的组件

8 实现：

考虑问题：

1）显式的父部件：父部件的引用支持责任链。

2）共享组件： 子部件将一些状态存储在外部，不向父部件发送请求，可以共享

3）最大化Component接口：

Composite模式的目的之一是，用户不知道使用的是Leaf还是Composite。

把仅对Composite有意义的操作放到Component，把Leaf看做没有子节点的Composite。然后Component提供缺省实现

4）声明管理子部件的操作

在Composite类层次结构中，哪一些类声明这些操作。

在Component中声明，是这些操作对Leaf有意义？还是在Composite和它的子类中声明并定义这些操作？

在安全性和透明性间权衡：

. 在类层次结构的根部定义子节点管理接口的方法良好的透明性，可以一致地使用所有的组件，以安全性为代价。可能做无意义的事，如在Leaf中增加和删减

. 在Composite类中定义管理子部件的方法比较安全。损失透明性，Composite和Leaf接口不同。

一般选择透明性，提供一个getcomposite。Leaf返回null  composite返回this

5）Component是否应该实现一个Component列表

6） 子部件排序

7）使用高速缓冲存贮改善功能

8）由谁删除Component

9）存贮组件最好用什么数据结构

9 相关模式：

部件-父部件模式用于责任链

Decorator与Composite一起用。通常有一个公共父类，装饰必须支持Add、Remove、GetChild的Component接口

Flyweight让你共享组件