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