结构型模式-组合模式.ppt

8.2 组合模式(COMPOSITE) 1.意图 将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。 2.动机 3.适用性 在下列情况下可以使用Composite 模式： 你想表示对象的部分-整体层次结构。 你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。 4.结构 典型的Composite对象结构如下图所示： 5.参与者 1. Component: 为组合中的对象声明接口。 在适当的情况下，实现所有类共有接口的缺省行为。 声明一个接口用于访问和管理Component的子组件。 (可选)在递归结构中定义一个接口，用于访问一个父部件，并在合适的情况下实现它。 Leaf: 在组合中表示叶节点对象，叶节点没有子节点。 在组合中定义图元对象的行为。 Composite: 定义有子部件的那些部件的行为。 存储子部件。 在Component接口中实现与子部件有关的操作。 Client: 通过Component接口操纵组合部件的对象。 模式原型代码 : 6.协作 用户使用Component类接口与组合结构中的对象进行交互。如果接收者是一个叶节点,则直接处理请求。如果接收者是Composite, 它通常将请求发送给它的子部件，在转发请求之前与/或之后可能执行一些辅助操作。 7.效果 定义了包含基本对象和组合对象的类层次结构 基本对象可以被组合成更复杂的组合对象，而这个组合对象又可以被组合，这样不断的递归下去。客户代码中，任何用到基本对象的地方都可以使用组合对象。 简化客户代码 客户可以一致地使用组合结构和单个对象。通常用户不知道(也不关心)处理的是一个叶节点还是一个组合组件。这就简化了客户代码, 因为在定义组合的那些类中不需要写一些充斥着选择语句的函数。 使得更容易增加新类型的组件 新定义的Composite或Leaf子类自动地与已有的结构和客户代码一起工作，客户程序不需因新的Component类而改变。 使你的设计变得更加一般化 容易增加新组件也会产生一些问题，那就是很难限制组合中的组件。有时你希望一个组合只能有某些特定的组件。使用Composite时，你不能依赖类型系统施加这些约束，而必须在运行时刻进行检查。 8.实现 1)显式的父部件引用 保持从子部件到父部件的引用能简化组合结构的遍历和管理。父部件引用可以简化结构的上移和组件的删除，同时父部件引用也支持Chain of Responsibility 模式。 通常在Component类中定义父部件引用。Leaf和Composite类可以继承这个引用以及管理这个引用的那些操作。 对于父部件引用，必须维护一个不变式，即一个组合的所有子节点以这个组合为父节点，而反之该组合以这些节点为子节点。保证这一点最容易的办法是，仅当在一个组合中增加或删除一个组件时，才改变这个组件的父部件。如果能在Composite类的Add和Remove操作中实现这种方法，那么所有的子类都可以继承这一方法，并且将自动维护这一不变式。 2)共享组件 共享组件是很有用的，比如它可以减少对存贮的需求。但是当一个组件只有一个父部件时，很难共享组件。 一个可行的解决办法是为子部件存贮多个父部件，但当一个请求在结构中向上传递时，这种方法会导致多义性。Flyweight模式讨论了如何修改设计以避免将父部件存贮在一起的方法。如果子部件可以将一些状态(或是所有的状态)存储在外部，从而不需要向父部件发送请求，那么这种方法是可行的。 3) 最大化Component接口 Composite模式的目的之一是使得用户不知道他们正在使用的具体的Leaf 和Composite类。为了达到这一目的，Composite类应为Leaf 和Composite类尽可能多定义一些公共操作。Composite类通常为这些操作提供缺省的实现，而Leaf 和Composite子类可以对它们进行重定义。 然而，这个目标有时可能会与类层次结构设计原则相冲突，该原则规定：一个类只能定义那些对它的子类有意义的操作。有许多Component所支持的操作对Leaf类似乎没有什么意义，那么Component怎样为它们提供一个缺省的操作呢？ 有时一点创造性可以使得一个看起来仅对Composite 才有意义的操作，将它移入Component类中，就会对所有的Component都适用。例如，访问子节点的接口是Composite类的一个基本组成部分，但对Leaf类来说并不必要。但是如果我们把一个Leaf看成一个没有子节点的Component, 就可以为在Component类中定义一个缺省的操作，用于对子节点进行访问