在写设计模式系列，暂停了对安卓系统的源码探索系列的更新的这对时间。
重新整理了下心情，打算重新继续开始写第17篇文章。
但越到后面越不容易，毕竟从UI看到Framework，再探索下去就是HAL层面，越到后面对能力的要求越高，同时耗费的时间和精力也必然会越多。一个不小不大的问题是对于过于底层的内容，暂时还不想去看。
写安卓程序也有两年多了，靠自学入门，平时的一点努力和当初一位做了六年的资深安卓开发人员指点，现在对基础的安卓开发基本没太大问题了，除了复杂的自定义控件依然觉得…
所以学到现在，显然也属于一段瓶颈期了，毕竟大多数APP套用下框架，补以一些第三方库，基本很快就可以开发完成，因此开发完一个APP所带来的兴奋也不再那么高了。
今天要说的是结构模式的最后一个，组合模式。
他和我们的数据结构里面的树有点关系，怎么个关系？
还记得我们在讲 设计模式4---对外包办的门面模型的案例提到的老板叫总经理干活，实际是下面别的部门的人在干活的案例吗？
现在我们来写一个基于组合模型的总经理叫各部门人员干活的过程。
单例模式垄断了对资源的访问，避免了多次生成带来的重复浪费。
但有时候，我们并没有这么严格的限制，还是希望多几个干活的，或者说
我们的实例有部分的重用功能，但又不能像单例那样只有一个，还是需要很多的实例。
具体如：
我们服务器缓存了100W个用户的信息，但是有一些冗余，例如我们的年龄只有100个取值，最多150是不是！但我们有100个用户，每个都有一个单独的年龄字段，相对是有点多余的，如果可以只压缩到100个的话。或者我们的用户里面的省会信息，也就34个！
好了，废话那么多，到底这个享元应该怎么写呢？
有一个叫控制反转(Inversion of Control，缩写IoC ) 的东西 ，这个对于计算机的人应该是不陌生的概念，就算你不知道那个Bob大叔。
这个概念简单说的是下面这样的事情
原本各个类之间的关系乱七八糟的，看起来头都晕了。
他们就像齿轮一样，相互咬合依赖。
如果有一个出问题，那可能整个就崩溃了。
但是，如果有一个人出来承担大事，负责协调各个类的话！
那么，他们的关系就可以是像下面图片这样的，
各个对象之间可以不感受到对方的“存在”，但整体又运作良好。
举个可能不恰当的例子：
企业ObjectA要招人，可能要去学校ObjectB开宣讲会，去别的企业ObjectC挖人等等。
有些人看到了其中的机会，专门负责为企业输送人才，我们称这类人叫猎头Ioc（也有人才中心等，这里为描述方便，不细究），他负责帮助企业去找到需要的人，我们的HR就可以在公司呆着，看着猎头源源不断发来简历就好了！
再也不用去和学校，别的企业打交道了。是的，从此HR与这两者解耦合,过上了幸福美好的生活!!
那么问题来了，如何用中介者模式来模拟这个招聘流程？
今天我们要聊的这个就中介者就是类似的情况，我们来看下实际的代码情况。
玩游戏我们都知道有个东西叫自动存档，在我们遇到大Boss要打的时候，更是如此，一定要存档！
如果没有存档，死了就要你重新开始，如果是些大型游戏，已经花费了你很多时间，遇到大Boss，然后你被打死了，又没有存档，估计你就想直接把这个游戏卸载了。
有时偷懒，还去下载别人的通关档案回来覆盖本地的。
哈，我就曾经做过！还有一些已经刷满无限金币等的存档！
曾经还遇到过必须被大Boss打死才能继续的剧情，但因为外挂太牛逼，活生生把大Boss给打死了！搞到后面都没法继续，只能自己手动滚回某个档案，装怂，去被boss虐下。
所以很好理解，这个自动存档会保存我们当前的角色的状态，然后如果被大Boss打死了，就自动恢复到这个存档点状态，我们还可以继续去打大Boss，直到我们过关为止。
那么问题来了，我们该怎么用代码实现呢？