最近写课程需求的时候，掌握了一些东西。尽量把胶合物集中起来，放在一个模块中，而不是零碎的分布在各处，会让代码看起来不那么刺眼。
举手头上的project。
有4个类，分别是CPlayer，IMonster，IDevice，ITerrainPortion。这4个类代表了整个游戏逻辑（规则），逻辑的执行通过两两相交碰撞来驱动。
在最初的设计中，每一个类都有接口对待其余3个类，也就是每一个类都知道规则的一部分。比如代码：
根据类型来向下转换是很烦人的，并且不同类型所用到的逻辑代码也大有不同。虽然说很想提供那么一个最高接口，给出统一的部署，省却转换，但是统一的部署首先是相当难做到，并且使得每个类的的有些行为的语意有些畸形。同时，统一部署之下，只是让接口看起来统一，但接口之下的实现确会更复杂。（完全说不明白）
按照这种分布式的胶合，增加了各个类型之间的耦合，因为每个类型都要区别其他类型，并执行恰当的代码，就先要知道其他类型的存在。
后来想到的集中胶合，由一个类，了解所有存在的类型，以及各个类型之间的规则，然后在实现中，根据两两的类型选择合适的处理函数，驱动逻辑。而其他类型本身，只要提供该类驱动逻辑时需要的方法就够了。
。。。。