MindPower中使用设计模式来提高程序库的可用性和弹性。例如,MindPower使用观察者(Observer)模式将自己的每一个状态变化通知给应用程序,客户端代码通过注册来监听MindPower中事件和状态的改变来得到相应通知。单件模式(Singleton)用来保证一个类只有一个实例,迭代器模式(Iterator)用来历遍一个数据结构中的所有数据。访问者模式(Visitor)可以让你在不改变对象的前提下,增加定义一个新的对象的操作。外观模式(Fa?ade)为子系统中的一组操作接口报漏给调用层一个统一的接口。最后,工厂模式(Factory)广泛的用来创建抽象接口的实例。
虽然没有得到权威的论证,但MindPower还是坚信场景图和场景内容的分离的设计一定是整个MindPower项目中最亮眼的地方。虽然看起来它是一个如此的简单易懂,不过对于那些仍然坚守“传统的设计方法”来完成场景图设计的人仍然会难以理解。
在传统设计中(就是很多商业和开源3D引擎所采用的)将场景内容和场景结构放到一个继承体系中,并将场景内容生硬的作为场景节点的子类。MindPower的开发者们认为这是一个极其失败的设计方案。如果不修改所有的子类,基本上是没有办法更改或者扩充图形算法的,因此让修改基类的接口非常困难,进而导致以后的维护工作变得举步维艰。此外这种“所有节点源自同一节点类型”的设计思想会让整个程序变得凝固且难以复用,特别是当增加新的基类功能方法或者属性的时候,不管是否真的需要,这些都强迫的塞入所有子类。最后导致哪怕是对基本功能做很小的修改,都会牵一发会动全身, 导致开发维护最终变得难与控制。这种糟糕的设计理念让陷入的人们痛苦不堪,从而希望摆脱这种逻辑采用全新的设计方法。
MindPower做到了。首先,MindPower对场景图的操作维持在接口级别;它并不关心去操作图形的具体算法实现。换言之,MindPower只是通过信号来操作场景图,进而忽略了具体的算法实现。其次,MindPower的场景图接口只负责维护场景结构。节点中没有包含任何固有的内容和管理方法。具体的内容被放置到一种可渲染(Renderable)对象之中,它提供了场景中全部几何图形。它们的渲染的属性被包含在实体(Entity)对象中,在实体对象里面同样包含着一个或多个子实体(SubEntity)对象,这些子实体才是是真正可以被渲染对象。图1 展示了场景图结构和场景内容之间的关系。注意:尽管场景节点挂接到场景图上面;但场景图仍然没有任何节点状态的直接操作。