SMM开发日志：第一次重构（Unity与游戏逻辑系统解耦，中介者、状态等模式的运用

起因

越深入阅读《设计模式与游戏完美开发》后，越发感到现在手头这个项目的代码架构可以有改进的地方。思考了一段时间后，整理了下当前的架构，决定将书上的一些优秀的实现融合到这个项目里。

思考

重构前的问题：

1、很多系统功能由挂载场景中的GameObject的继承自MonoBehaviour的Script实现（我命名为XXController，原意是照搬以前javaee的MVC模式）。其问题在于，这些功能GameObject之间的交互要通过 Find(场景中GameObject的名字).GetComponent< XXController > 。这样配置各个系统时麻烦（要记住名字），继承了MonoBehaviour阻碍了解耦、实现多态等未来的扩展，类之间的依赖难以管理，不优雅。

2、Flowchart只与唯一的FlowChartController交互。所以flowchart需要的方法，FlowChartController都要有，拥有了大量依赖，使其成了臃肿的“神仙大类”。而且以前没有自定义指令，所以flowchart都是通过Invoke指令调用FlowChartController的方法。

3、由Director控制场景切换。Director继承自MonoBehaviour上并挂载在场景中。每个场景的Director都将要转换的下一个场景名硬编码，产生了多个类。（我当初省事就这样设计了，很蠢）

工作

1、将各个系统与Unity解耦。使用唯一挂载在场景中的继承MonoBehaviour的游戏主循环GameLoop来Update各个系统，各个系统组件不再继承MonoBehaviour，挂载在场景中。（即将各系统的随Unity主循环的Update分离出来由GameLoop负责）

2、按状态模式，使用SceneStatrController和SceneState来控制场景的切换和初始化。

3、按中介者模式，将各个系统作为SMMGame的成员，由SMMGame负责它们的初始化和交互。并将SMMGame设为单例，避免重复生成，并方便调用。

4、抛弃FlowchartController，由flowchart中的自定义指令与各个系统实现功能。它们通过调用SMMGame的单例的方法（外观模式，SMMGame对外屏蔽各系统，解耦了指令对各个系统的依赖）或让消息收发者SMMUIDispatcher发送消息或直接操作场景对象来实现功能。

5、按桥接模式、工厂方法，设置UIController和UIInterface两个类群组。按不同的场景，使用不同的UIController，初始化和控制不同的UIInterface。