GoF《设计模式》中说到：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得客户对单个对象和组合对象的使用具有一致性。
下面我对一些具体情况分析，其中会引出一些问题和思考中的闪存以及相应的解决方法。
实际中的无限级分类，看起来就是一个的Composite的例子。
Category具抽象元件、图元、图元容器于一身。应该说它没有图元的概念(到底有没有是有领域概念来决定)
Category看起来可能是像这样的：
大致代码如下，
public class Category
{
private string m_CategoryId;
private string m_Name;
private ArrayList m_Childs;
public string CategoryId{get{return m_CategoryId;}set{m_CategoryId=value;}}
public string Name{get{return m_Name;}set{m_Name=value;}}
public ArrayList GetChilds(){return m_Childs;}
public void Add(Category c){m_Childs.Add(c);}
public void Remove(Category c){m_Childs.Remove(c);}
}
上面代码具体情况不同也改进也不同。
可能会涉及到几个方面：
一、在Remove操作的时候，我们可能最容易得到的是CategoryId，这时我们需要遍历(这里涉及到Iterator模式，不过该模式已经得到语言的支持，它已过时)查找得到这个Category对象)。然后再进行Remove(Category c);这里可以使用Dictornary来代替ArrayList，key存储CategoryId,Value存储该对象Category，当然这仅仅是一种实现方式.
这里的获取操作有两种实现。
(不缓存)用CategoryFactory重建出来
(缓存)1、职责的任务仅仅是查找，有客户来执行删除2、职责的任务是查找并删除{整棵树需要显示的父部件引用}。如果整棵树比较庞大，这样的遍历非常不值。
缓存策略:一旦部件发生变化，缓存失效。这里缓存实现大致两种：1、整棵树缓存到一个value中。2、每个部件缓存一个value。不过gof原著指的应该是第二种，对于庞大的树来说很好。
二、gof中的问题，对于Component是否要实现一个Component列表；
这里看下.net类库中的做法。控件在获取子控件的时候有一个方法，EnsureChildControls();也就是在需要的时候才去创建这个列表。另外Add,Remove不需要做额外操作时，它们没有存在的必要，由集合数据结构代替。Control中就是如此。
此列表更新。。。
组合模式的应用：
实际中可能需要对某些对别添加功能。比如有些类别是热门类别，需要在名称上有些变化，或别的。这时可以应用Decorator模式。