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让你共享组件