组合模式是一个很实在的设计方式，完全基于顺势的思维。
对于一个可以被细分，且细分后可以统一处理的事物。这里必须例如一下。。。
例如：学籍管理系统，管里系统中有年级，学院，班级，学生。
每年，总有那么几个班级不知道是哪个院的，每个院总有那么几个学生是奇奇怪怪不知道是哪个班的，但是系统也得处理不是。
于是就是这样：
对于这个系统里所有的对象，不管是个院还是一个人，都有通用的操作，比如，打印成绩。比如，算平均分。
其中，各个院算法不同，但是外部不需要知道哪里不同，我要平均分给我平均分就行。
在整个系统运作的时候，需要一些用来管理的方法。
比如，一个班级，需要添加，删除一个娃娃，一个学院，可以添加删除一个班级/一个不知是哪个班的娃娃。
对于系统中最小的个体（这里是娃娃），这种添加和删除是木有意义的（生孩纸什么的不讨论[严肃][严肃]）
所以，这里就需要解决这个问题。
通常的，前辈们把这个叫做，透明性和安全性。
这两种都各有那么些蛋疼的地方。
所谓透明，就是我们承认小明还能生小小明，但是对小明来说基本实现不了了（小明是男娃）
所以，我们给小明 添加/删除 这两个属性，但是这俩方法是没有实际效果的。
这样的好处是，在外部，可以完全不需要区分，小明是娃娃还是小明是一个学院。who cares
安全性，就是，不给小明 添加/删除 的方法。把娃娃和娃娃的集合区别开。
透明和安全的选择
看爱好了，喜欢就好，只要系统不会失控，怎么都行。
如果喜欢透明更多一点，可以为每个对象增加一个附加方法，返回 ”我是啥“
如果是最小节点，返回空的，如果是集合，返回可用对象的指针 this
描述一下写法，所有对象都继承自同一个基类
基类包含最基本的管理方法
Add，Remove，。。。。。。
GetComposite
和通用方法
Prient。。。。
实现相关的要考虑的东西。
1.对父节点的引用。
简化管理，提供一个可以获得父部件的方法。
把父部件当做一个纯集合，它的变化，仅仅因为子部件的增删。
2.
共享组件。
这个在前面的例子里比较难实现，因为学籍管理这种例子不论是娃娃还是娃娃的集合都是唯一的。
所以不存在什么共享。
但是，如果一个系统中一个子部件被多个父部件包含。。被多人包养。。
那只要一份子部件就可以。然后它拥有多个父部件。。
3.设计时的准则-最基的基类，接口要最大化。
或者在开发的过程中，发现有大家都可以用的方法，就丢到基类里去。
就最大化原则来看，透明性好一点
4.强化对子节点的访问
子节点比较少的时候，可以考虑在基类里写子部件列表
用这个列表管理子节点。
个人感觉这个挺麻烦的。。。
5.查找量很大的时候
用类似缓存的结构，父部件缓存子部件的查找信息。缓存信息在子部件变动较少（子部件变动缓存就失效了）时比较实用。
这个在数据量很大查找很频繁的时候需要注意。
其他时候选对适用的数据结构即可
6.数据结构选用
这个纯看需求，看做什么东西。
是要便于查询还是便于删增还是便于遍历
7.统一的释放机制。
释放父部件，子部件会被父部件自动释放。
