问题：

图11-1和图11-2 参见 http://blog.csdn.net/u012829152/article/details/42172233；11-1的对象图中，fishGUI系统内与窗口元素相关的对象，在系统运行的某一刻构成了一个三层的属性结构，并显示了对象之间的包容关系；而在设计模型内与窗口元素相关的类图11-2中，所有类又构成了另一个树形的继承结构，这两个树形结构并不完全相同，如二者的层次数量不同，特定的类和它对应的对象实例在二者中的位置也不一致，如果设计模型无法反映这些差异，程序员就必须在代码中自行处理这些差异，必然导致设计和编码的脱节，影响系统最终的质量

为了在fishGUI与窗口元素相关的类图中完整体现类于类之间的包容关系，需要在原来的类继承树之上，在根据窗口元素间包含与被包含的层次，补充类间关系，即如何在一个统一的类图中表达继承和包含这两层逻辑关系

复合模式

设计意图：当一个系统中的对象需要组合成树形结构，以表示整体和部分的层次关系时，就可以使用复合模式。在复合模式的继承树中，一部分派生类在整体和部分的聚合关系中是简单的被聚合对象，其内部不能再聚合其他对象，而另外一部分则可以聚合该继承树中任何非抽象类的对象实例。复合模式可以通过继承树，使客户程序一透明和统一的方式，访问继承树中所有类的对象实例，对于客户程序来说，符合模式中简单的被聚合对象和可以聚合其他对象的符合对象之间，并没有什么区别。继承关系的统一性和聚合关系的实用性得到了最好的结合

基本结构：实现符合模式的关键是建立一个抽象类来代表所有简单对象和复合对象，使它们拥有公共的接口，系统中的简单对象和复合对象都是这个抽象类的派生类

部件（Component)类：整颗继承树的抽象类，定义了整颗树中所有类的接口，其中包括管理和访问被聚合部件的接口，在这个抽象类中，可以实现一些缺省的行为，有时也需要定义访问上层部件的方法，这样可以使遍历整颗对象树的效率更高

叶子（Leaf）类：代表整颗树中的叶子不见，叶子部件内部没有被聚合部件。在叶子部件中，我们可以定义简单对象的行为

复合（Composite)类：代表整颗树中的复合部件，复合部件定义了复合对象的行为，其中包括管理和访问被聚合部件的接口的是想方法。复合部件还需要关心多个被聚合部件的存储方式

客户程序一般通过部件类的接口访问整颗继承树

透明的复合模式实现：每个复合类中可以聚合任何一种叶子类或者复合类的对象实例，形成了递归的复合结构；为了使客户程序能透明地访问所有的对象，抽象类Component中必须定义所有派生类需要的方法，即包括和聚合关系相关的方法，也包括简单对象和复合对象共有的方法，对于类的数量较少的继承，往往是首选的。但是这种方案的职责分配不够清晰

：

安全的复合模式实现：严格限制了每个复合类所能聚合的对象种类，并以此保证了类职责的清晰。这种实现方案里，不提供透明的访问方式，客户程序需要通过每一个具体的派生类接口执行相关操作。同时从复合类返回的对象指针一定是客户需要的所以不需要强制类型转化。缺陷是每个复合类所能聚合的对象种类有限，很难实现代码的复用，此外客户程序在调用复合对象或者叶子对象的相关接口是，操作过程会非常繁琐

fishGUI：复合模式