代码说明

　　Element类型就是抽象构件的角色，它给组合对象以及单个对象提供了一个一致的接口，使得它们都能有一致的行为。

　　这里就出现一个问题，组合对象需要通过Add和Remove方法来为其添加子节点，而最底层的树叶构件下并没有任何子节点，在接口中定义这些操作子节点方法的方式叫做透明方式的合成模式，缺点就是不够安全，容易在运行时出现异常。如果把这些操作子节点的方法定义从抽象构件中删除，由各树枝构件来实现的话，就是安全方式的合成模式，缺点也就是不够透明。具体怎么做还要根据自己的需求。

　　GameService当然就是树叶构件，如果调用它的Add以及Remove方法会抛出一个异常。当然，你也可以以其它方式来记录这种逻辑错误。

　　GameServer是一个树枝构件。一个游戏服务器上会有多个游戏服务。这里注意到一点，在开启服务器上所有服务的时候，我们对服务进行了排序，排序是按照服务的类型进行的。然后，我们按照服务类型从大到小的次序开启了服务。一般一个网络游戏的服务会有很多种，而这些服务的开启是有先后次序的，先开记录日志的服务、排名服务、再开数据交换的服务、最后才是大厅服务等。我们不可能让用户进入大厅的时候没有地方写数据和日志吧。开启服务是按照次序的，那么关闭服务也就是按照相反的次序了。

　　从上面这点，我们就可以看到组合模式的好处了，树枝构件在管理树叶构件的时候通常还会有一些逻辑，不会是简单的增加和删除操作。如果这些工作交给客户端去做的话，就太不合理了。

　　最上层的树枝构件就是GameArea类型。它并没有什么特殊的地方。

　　何时采用

　　从代码角度来说，如果类型之间组成了层次结构，你希望使用统一的接口来管理每一个层次的类型的时候。

　　从应用角度来说，如果你希望把一对多的关系转化为一对一的关系的时候。

　　实现要点

　　使用透明模式还是安全模式根据自己的需要定。

　　在某些情况下，树叶构件可以访问树枝构件获取一些信息。

　　如果树叶构件数量比较多，树枝构件频繁遍历子节点的话可以考虑进行缓存。

　　既然所有对象有了统一的接口，客户端应该针对抽象构件进行编程。