组合模式-系统由可以被统一处理的对象组成，对象可以单一或者复合

做一个资深标题党，专注于用标题表达一切。

组合模式是一个很实在的设计方式，完全基于顺势的思维。

对于一个可以被细分，且细分后可以统一处理的事物。这里必须例如一下。。。

例如：学籍管理系统，管里系统中有年级，学院，班级，学生。

每年，总有那么几个班级不知道是哪个院的，每个院总有那么几个学生是奇奇怪怪不知道是哪个班的，但是系统也得处理不是。

于是就是这样：

对于这个系统里所有的对象，不管是个院还是一个人，都有通用的操作，比如，打印成绩。比如，算平均分。

其中，各个院算法不同，但是外部不需要知道哪里不同，我要平均分给我平均分就行。

在整个系统运作的时候，需要一些用来管理的方法。

比如，一个班级，需要添加，删除一个娃娃，一个学院，可以添加删除一个班级/一个不知是哪个班的娃娃。

对于系统中最小的个体（这里是娃娃），这种添加和删除是木有意义的（生孩纸什么的不讨论[严肃][严肃]）

所以，这里就需要解决这个问题。

通常的，前辈们把这个叫做，透明性和安全性。

这两种都各有那么些蛋疼的地方。

所谓透明，就是我们承认小明还能生小小明，但是对小明来说基本实现不了了（小明是男娃）

所以，我们给小明 添加/删除 这两个属性，但是这俩方法是没有实际效果的。

这样的好处是，在外部，可以完全不需要区分，小明是娃娃还是小明是一个学院。who cares

安全性，就是，不给小明 添加/删除 的方法。把娃娃和娃娃的集合区别开。

透明和安全的选择

看爱好了，喜欢就好，只要系统不会失控，怎么都行。

如果喜欢透明更多一点，可以为每个对象增加一个附加方法，返回 ”我是啥“

如果是最小节点，返回空的，如果是集合，返回可用对象的指针  this

描述一下写法，所有对象都继承自同一个基类

基类包含最基本的管理方法

Add，Remove，。。。。。。

GetComposite

和通用方法

Prient。。。。

实现相关的要考虑的东西。

1.对父节点的引用。

简化管理，提供一个可以获得父部件的方法。

把父部件当做一个纯集合，它的变化，仅仅因为子部件的增删。

2.

共享组件。

这个在前面的例子里比较难实现，因为学籍管理这种例子不论是娃娃还是娃娃的集合都是唯一的。

所以不存在什么共享。

但是，如果一个系统中一个子部件被多个父部件包含。。被多人包养。。

那只要一份子部件就可以。然后它拥有多个父部件。。

3.设计时的准则-最基的基类，接口要最大化。

或者在开发的过程中，发现有大家都可以用的方法，就丢到基类里去。

就最大化原则来看，透明性好一点

4.强化对子节点的访问

子节点比较少的时候，可以考虑在基类里写子部件列表

用这个列表管理子节点。

个人感觉这个挺麻烦的。。。

5.查找量很大的时候

用类似缓存的结构，父部件缓存子部件的查找信息。缓存信息在子部件变动较少（子部件变动缓存就失效了）时比较实用。

这个在数据量很大查找很频繁的时候需要注意。

其他时候选对适用的数据结构即可

6.数据结构选用

这个纯看需求，看做什么东西。

是要便于查询还是便于删增还是便于遍历

7.统一的释放机制。

释放父部件，子部件会被父部件自动释放。