<p$1$2$3$4$5$6>
有几个模式比较重要和基础的。
第一个是关于构建对象的模式。
<p$1$2$3$4$5$6>
接口 a = new 类b（）；
<p$1$2$3$4$5$6>
这个就是构建对象的代码，这个代码应该怎样处理。从位置来看，在组合模式下，假设类a包含类b，如果将构建代码放在类a中，必然导致类a对类b的强引用，当类b有所变更，可能就会影响类a的代码。但是类a如果不对类b进行引用，就无法组合代码了。基于这个些要求，应该把以上代码放在一处地方，这个地方是关于业务的主线的。
<p$1$2$3$4$5$6>
类a 和 类b 直接通过接口作为纽带，是间接的，而最终关联的代码由业务主体类c来负责。比如：
类a { 接口a };
类b;
类c { 类a.接口a = new 类b; } //通过负责业务的类c来拼接业务。
<p$1$2$3$4$5$6>
假设有新的业务需求类d。
类e; //新的功能组件
类d { 类a.接口a ＝ new 类e;} //拼接称类d业务。
<p$1$2$3$4$5$6>
可见，类a 和 类b 是没有必然的联系的，她的联系是建立在业务需求之上，因此应该由相关的业务类来组建他们的关系。
为了灵活起见，甚至可以将创建这种联系的代码放在外部配置文件上，由管理人员灵活操控。这就是创建模式。
<p$1$2$3$4$5$6> <p$1$2$3$4$5$6> <p$1$2$3$4$5$6>