最近要开一个新的项目（由于保密原因不能说具体是什么，但仍然是AR项目），想到终于可以重构我之前那恶心的代码了，不过目前时间也只允许我在新项目中重构，不过想来也是件好事，毕竟刚好可以通过它打磨好我新重构的模块，将来放回原项目里也算比较稳妥。
    其实我们的APP在最初设计时并没有现在这么多的产品线，但架不住对于用户喜好的试探，如我曾经做过的大多数项目一样，做了无数次的修改，由于每次时间压的非常紧，后期我已经基本已业务需求为第一优先级了，新开发的各种功能都是基于我最初的架构，通过最近再给手下分配工作内容时发觉有些模块已经互相交织在一起，不利于分配单独模块的工作了，在这之前已经产生过无数次想要重构代码的冲动，无奈都架不住公司节奏太快，完全没有时间，这一次也算是借此机会重构了下我之前开发过程中最痛苦的一部分，并非全部工程。
    其实通过一年多的AR业务的相关开发，对于AR引擎核心层的业务主要就是引擎的启动，平面的识别，操作交互三个方面，我觉得任何一个AR相关APP都少不了这些，而我曾经一直把我们产品自己得业务直接混入到引擎的这三个业务里面，而不同的产品线在这三个业务里的处理又都不同，导致AR引擎代码里参杂了太多业务代码，而这一次的重构，主要就是要剥离AR引擎业务和我们自己的产品业务，主要的方式是改为了消息机制。正如我刚才说的，对于AR引擎本身来说主要就是启动，平面识别，操作交互，那么我就将AR引擎启动完成，平面识别等等这些时机作为一个事件分发出去，也就是说AR引擎只告诉我自己得业务逻辑它现在发生了那些事件，至于怎么处理这些事件，由我自己得业务逻辑模块去监听，然后实现，比如现在识别到了平面，我只告诉你识别到了平面，并且把识别到的平面的信息作为参数传给业务模块，至于业务模块拿到这些信息是要展示？还是做其他什么？都与AR引擎无关，做到AR引擎自己的业务逻辑和产品的业务逻辑彻底分离。另外关于消息机制这里我曾经自己的框架里封装了一份，不过最近又好好看了下C#中的event关键字，大概由于我是一直以Java的为基础来使用C#的吧，所以C#还有很多特性并没有全部熟悉，这次刚好发觉这个event关键字似乎就是为了消息机制而准备的，实现一套消息机制似乎比我之前写的那个完全基于通用面向对象语言的消息模块要容易许多，可以理解为C#已经帮我们做了。这次在新项目上改为消息机制驱动以后，总算看着条理清晰了许多，不像之前那么混乱了。