Delta3D 源码阅读笔记

dtCore::Base
这个是所有“重型”类（heavy-weighted）的基类，主要实现两方面特性：
1、自身管理，包括命名、维护
instance 列表；
2、消息管理，主要是用 signal-slot
机制。

dtABC::BaseABC
这个类不大，但相当杂。理解起来，应该从 namespace 的名字入手。我猜想 ABC 的意思大概是
Application Base Class ，这样的话，BaseABC 当然就是 Delta3D 应用的最基本框架了。这个类的确包括了一个 Delta3D
应用的所有基本要素：窗口、视图、场景、键盘、鼠标、事件。感觉这个类的设计相当失败：
1、为了共享代码，而设计了一个
std::vector<dtCore::View> 的成员变量，而自身却没有提供任何方法来存取除第一个之外的
view；
2、为了一时方便，提供了诸如 AddDrawable、LoadMap 之类本该属于 Scene 类的方法；提供了诸如 SetCamera
之类本该属于 View 类的方法；
3、这些“预设未来”式的设计，使得除框架中提供的 Application 之外的设计变得相当困难，BaseABC
这个类因而相当难以用于扩展继承。既然如此，要这个类做什么呢，何不合并到它的下级子类之中呢。

dtCore::InputDevice,
dtCore::Mouse, dtCore::InputFeature, dtCore::Axis ...
这是一系列的类，用来实现用户输入响应。只看了
mouse 部分，keyboard 基本一样。手工在纸上绘了一份 UML 图，但是另外去找绘图工具画出来显然太麻烦……总的说，大体上 InputDevice
是一个抽象类，Mouse 是它的一种实现类；一切 InputDevice 均可包含若干InputFeature；InputFeature 是一个抽象类，有
Button 和 Axis 等实现类；每个 Button 和 Axis 均可挂接若干 Listener 来响应 StateChanged。而为了更好的使用
Axis ，有多个 adapter，如 ButtonsToAxis ，AxisToAxis 等等，这样一来，我们可以把 W 键和 S 键组合成一个 Axis，A
键和 D 键组合成另一个 Axis ，从而组合形成规范精巧、概念清晰的用户输入响应代码。另外，Mouse 和 Keyboard 等在 InputFeature
的 Listeners 之外可以拥有自己的 Listeners，从而能在 InputFeature
的层次之上处理用户输入。
总体而论，这是一个相当精致的抽象，相关华美的设计。可惜的是，设计者还是过于自负了——Mouse 被 View 持有（通过
KeyboardMouseHandler），而 View 的创建过程客户程序员难以介入，这样一来，Mouse
事实上是不可“织入”的，客户程序员不能创建一个自己的 Mouse 类并交给 View；再往下，我曾想过可以用 AddFeature 、RemoveFeature
来介入，但是用处显然没有想象的那样大——因为，Axis 的 SetState 方法居然不是 Virtual，这意味着我只能放一个标准的 Axis
进去，毫无意义。这个报怨不是纯思辨的，因为：如果要实现一个 FPS 游戏式的 MotionModel 的话，Axis 机制是不行的。回头去看了 Delta3D
自己的 FPSMotionModel，虽然假装装配了一大堆 Axis ，然而最后还是自已去响应 Mouse 的 Listener，在 Axis
层面之上处理问题，事实上没有用到 Axis，这才得以回避“何时复位鼠标位置”的难题。
Delta3D 还应该多为客户程序员着想，而不是只考虑
SimCore 的需要。也许，应该直接使用 SimCore ？