15 Composite组合模式（结构型）

版权声明：就是开个版权玩一下 https://blog.csdn.net/qq_41997479/article/details/86651193

15 Composite（结构型）

 

 

• • 
  • 类似于数据结构中的List (列表).
  • 动机：
    • 图形应用程序(如绘图编辑器和示意图捕获系统)允许用户用简单的组件构建复杂的图表。

用户可以将组件分组以形成更大的组件，然后再将这些组件分组以形成更大的组件。

 

• • 
  • Component：定义接口，接口分离原则  是单一职责原则在接口上的一种表示
  • composite：存储child component
  • 

• • 什么时候用：
    • 您希望表示对象的部分-整体层次结构。
    • 您希望客户端能够忽略对象组合和单个对象之间的差异。客户端将一致地对待组合结构中的所有对象。
  • 合作：
    • 客户端使用组件类接口与复合结构中的对象交互。
      • 如果接收方是一个叶子，那么请求将被直接处理。
      • 如果接收方是一个组合，那么它通常将请求转发给其子组件，可能在转发前和/或转发后执行其他操作。
  • 结果：
    • 定义由基本对象和组合对象组成的类层次结构。
    • 使客户端简单。
    • 使添加新类型的组件变得更容易。
    • 可以使设计过于一般。
      • 易于添加新组件的缺点是，它使限制复合组件变得更加困难。
  • 实现：
    • 孩子节点增加一个指针指向parent（类似于三叉链表）
    • 
    • 复合模式使客户端不知道他们正在使用的特定叶子或复合类。
      • 组件类应该定义尽可能多的常见操作复合类和叶类。
      • 组件支持的许多操作似乎对叶类没有意义。与ISP与LSP法则冲突
    • Leaf如何为它们提供默认实现?
      • 执行无用的操作，什么也不做，或者返回null，或者返回模拟对象，或者抛出异常。
    • 有序树要注意子树的顺序
    • 我们应该在组件中声明“子管理操作”并使它们对叶类有意义，或者我们应该仅在复合类及其子类中声明和定义它们?
      • 该决定涉及安全与透明度之间的权衡:
        • 透明性:在组件中定义子管理接口可以提供透明性，因为您可以均匀地对待所有组件。它的代价是安全性，因为客户机可能尝试从叶子中添加和删除对象。

 

• • 安全性:在组合类中定义子管理提供了安全性，但是失去了透明性，因为叶子和组合具有不同的接口。

 

• • 许多设计都指定了对Composite的子元素的排序。
  • 当子顺序是一个问题时，您必须仔细设计子访问和管理接口来管理子顺序。

 

• • 如果需要经常遍历或搜索组合，则组合类可以缓存关于其子类的遍历或搜索信息
    • 为了提升效率，让parent持有孩子节点的高速缓存
    • 对组件的更改将需要使其父组件的缓存无效。
      • 当组件知道它们的父组件时，这种方法最有效。（如使用三叉链表）
      • 因此，如果您正在使用缓存，您需要定义一个接口来告诉组合它们的缓存是无效的。
  • 存储组件的最好数据结构：选择适当的容器Arrays, List, Set, HashMap

• • 举例：
    • 
  • 变种：没有叶子节点的
    •