动机：
客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构（而非抽象接口）的变化将引起客户端代码的频繁变化，带来了代码的维护性、扩展性等弊端。
如何将“客户端代码与复杂的对象容器结构”解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？

意图：
将对象组合成树形结构以表示“部分--整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。

要点：
1、Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地处理对象和对象容器，无需关心处理的是单个对象，还是组合的对象容器。
2、将“客户代码与复杂的对象容器结构”解耦是Composite模式的核心思想，解耦之后，客户代码将与纯粹的抽象接口（而非对象容器的复杂内部实现结构）发生依赖关系，从而更能“应对变化”。
3、Composite模式中，是将“Add”和“Remove”等和对象容器相关的方法定义在表示抽象对象的Composite类中，是一个关乎“透明性”和“安全性”的两难问题，需要仔细权衡。这里有可能违背面向对象的“单一职责原则”，但是对于这种特殊结构，这又是必须付出的代价。ASP.NET控件的实现在这方面为我们提供了一个很好的示范（例如：Button、Panel等情况，调用重绘时，Panel不仅重绘自己还将重绘容器中的控件）。
4、Composite模式在具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。

 //---------------------------------------------------------------------------------------
//问题原形
 public interface IBox
 {
  void Process();
 }
 public class SingleBox : IBox
 {
  public void Process()
  {
  }
 }
 public class ContainerBox : IBox
 {
  public void Process()
  {
  }
  public ArrayList GetBoxes()
  {
  }
 }
 //客户代码
 public class App
 {
  public static void Main()
  {
   IBox box = Factcry.GetBox();
   //客户代码与对象内部结构发生了耦合
   if(box is ContainerBox)
   {
    box.Process();
    ArrayList list = ((ContarainerBox)box).GetBoxes();
    //.....  //将面临比较复杂的递归处理
   }
   else
   {
    box.Process();
   }
  }
 }
 //---------------------------------------------------------------------------------------
 //使用组合模式进行改进
 public interface IBox
 {
  void Process();
  void Add(IBox box);
  void Remove(IBox box);
 }
 public class SingleBox : IBox
 {
  public void Process()
  {
   //..........
  }
  //在该方法中，此处有点问题，会出现操作无效
  public void Add(IBox box)
  {
   throw new Exception("不能添加盒子");
  }
  //在该方法中，此处有点问题，会出现操作无效
  public void Remove(IBox box)
  {
   throw new Exception("不能移除盒子");
  }
 }
 public class ContainerBox : IBox
 {
  ArrayList list = new ArrayList();