开发日志 5-28

     All things are difficult before they are easy .

      ...........  * *  *...................... *  *  *....................................

  

      1） 拆分大函数：

 　　因为最初的设计师从一个人物出发的，所以很多把主函数写得非常庞大。我现在要把这个怪物“庖丁解牛”。当然了有哥们问：那为啥不开始就考虑到分解函数？凡事从无到有，从简陋到复杂优雅。Pratice make prefect.如果开始从一个很复杂的系统考虑，必然给入手带来极大的困难，“老虎吃天，无处下口”。Zhe shortest answer is doing.对于做开发而言，入手是非常重要的。在实践的过程中发现很多很多的问题，有了一定的感觉，在一定时间之后进行重构，或许是更靠谱的做法。当然，这个过程是痛苦的，这毫无疑问。“不破不立”，世间之理乃然。

      拆分大函数：

　　I: 现在我要让很多东西有区别的共用这个“人物类的”主函数，比如道具——一个可以被打破的坛子（或许里面还有一盘香喷喷的大包子），那么这个坛子就需要有两个动画序列，并且能检测碰撞。怪物和玩家的主函数相似度更高，但怪物是不必响应键盘鼠标的，但需要具有很高的自治性AI，而玩家相反。从中可以看到，这些实体都有一定的共性，如果希望能够使用这些共性，就需要把最初设计的“大函数”拆解开来。（一点题外话，想起来在FSM中，状态内部有一个Execute（）方法，好像和这个还有点联系；暂时先不管他了，仔细研究一下FSM，等下一步的重构吧）使用has-a 的方式。

　　II:把一个大的函数拆分成小段，对于.net机制来说，有着优化的意义，性能上会得到提高。

  2）向上转化和向下转化

　　这是纠结了很久的问题，因为逻辑处理需要共同的函数，但是数据需要独特的，而每个实体需要处理的数据模板都不一样，这样在处理函数那里，处理到了不同的类型的时候，就需要进行类型转化，而这对于效率是否会带来影响，是心存疑虑的。（我忽然想到有一点遗漏了，刚才说拆分函数供各种实体使用，那么实体的数据类型怎么区别呢？）如果你使用as来转换数据，那么用is来做检测是不必要的。只用检测返回类型是否为null就行了，这很简单。