设计模式－－composite－－结构型

在面向对象系统中，我们常会遇到一类具有“容器”特征的对象
－－即它们在充当对象的同时，又是其他对象的容器。
 

public class SingleBox:IBox
...{
 public class process()
...{ .....}

}
public class ContainerBox:IBox
...{
public void process()
...{ ... }
public ArragList getBoxes()
...{ ...}

}



如果我们要对这样的对象容器进行处理：
 class App
...{
public static void Main()
...{
 IBox box＝Factory.getBox();

//客户代码和对象内部结构发生了耦合
if(box is constrainerBox)
 box.process();
ArryList list=((ConstrainerBox)box).GetBoxes();
....//
}else if( box is SingleBox)...{
box.process();
}
}
}

在用contrainBox 必须知道对象的结构,在复杂的情况还要在
客户端进行排序。
如果客户和业务对象最好直接和接口发生依赖---就是和IBox发生依赖
而我们的代码中客户和ConstrainerBox 发生依赖。。
这样就存在问题－－业务发生变化客户就会不能运行

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

原则：   接口最小化－－就是业务对象有些方法是自己调用和客户端
调用，把客户调用方法在接口声明，就可以屏蔽那些自己调用的方法

意图（Intent）

将对象组合成树形结构以表示“部分－整体”的层次结构。

Composite使用户对单个对象和组合对象的使用具有一致性。

结构（struture）

pulic interface IBox
...{
 void process();
 void Remove(IBox box);
 void Add(IBox box);
}


public class SingleBox:IBox
...{
 public class process()
...{ 
 //1. DO process for myself
  ....
}
 public void Add(IBox box)
...{  
 throw new Exception("不能添加，我不是容器")

}
public void Remove(IBox box)
...{
   throw new Exception("不能删除，我不是容器")
}

}


public class ConstrainerBox:IBox
...{

  ArrayList list=null;
 public void Add(IBox box)
...{
  if(list==null)
  list=new ArryList();
  list.add(box)

}
public void Remove(IBox box)
...{
  if(list!=null)
  list.remove(box)
}


public void process()/**////树形结构出来了
...{ 
  //1. DO process for myself
  ....

  //2.Do process for the box in the list
    if(lis!=null)
...{
  foreach(IBox bos in list)
 ...{
   box.Process();   
}
}

 }


}


class App
...{
public static void Main()
...{
 IBox box＝Factory.getBox();

 box.process();//这样就可以个抽象接口发生耦合。
              //也是我们要的


}
}
}

Composite模式的几个要点

   • Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一
对多”的关系转化为“一对一”的关系，使得客户代码可以一致地处理对
象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。
• 将“客户代码与复杂的对象容器结构”解耦是Composite模式的核心思
想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的复
内部实现结构——发生依赖关系，从而更能“应对变化”。

• Composite模式中，是将“Add和Remove等和对象容器相关的方法”定
义在“表示抽象对象的Component类”中，还是将其定义在“表示对象容
器的Composite类”中，是一个关乎“透明性”和“安全性”的两难问题，
需要仔细权衡。这里有可能违背面向对象的“单一职责原则”，但是对
于这种特殊结构，这又是必须付出的代价。ASP.NET控件的实现在这
方面为我们提供了一个很好的示范。

• Composite模式在具体实现中，可以让父对象中的子对象反向追溯；
如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。

   composite在现实实现很都比如 菜单,panel--constrain Button--叶子接点