游戏中的抽象系统设计

这是一篇讲思维模式的文章，如果你耐着性子读完，你可能会对此嗤之以鼻，无论什么原因驱使你这样想，那么请理解，在实际开发过程中，这个思维模式行之有效，并且避免了很多不必要的麻烦。有些人读完了可能会觉得这个就是再讲架构设计，但我更愿意把它拆分为两部分，为了是更好的“设计架构”。

这篇文章最后的结论会有一下几个：

1、致命性的BUG很多时候都是由抽象系统设计缺陷导致的。 2、抽象系统设计就是让人厌恶的按流程办事，但他会让你感到快乐。 3、抽象系统设计不等同于架构设计。

针对这三个总结，我会一一说明，但维度不同。

总结一

致命性BUG理论上来说无法解决，当然，这和运行环境变化等都无关。当你实现某一个功能并认为它可以正常运行的时候，却发现事实并非如此。检查后发现，如果想修复此BUG，需要修改原有程序结构，或者破坏某种设计规则，那么这种致命性BUG就是由抽象系统设计缺陷引起的。

举一个小小的且矫情的例子，iOS系统中对于每个App都有一个安全的域。当你想在磁盘中写入文件时，你可选择的磁盘位置非常有限。如果你写入了非法磁盘位置，此时会引发系统报警，并且写入失败。这是个典型的致命性BUG，之所以说致命是指，如果你的设计中确实需要向非法路径中写入数据，那么这个抽象设计是错误的。

总结二

如果你看过Linux程序设计，你应该对此有所感悟。所有人都明白两点之间线段最短，从A到B最快的方式就是直线，当很多时候，A到C，再到B才是最好的选择。因为A到B中间可能有一条永远也无法逾越的大河。获许你可以从中建立一个非常结实的桥梁，但会因此破换自然环境（此处寓意为破换原有程序设计）。

你的所有业务逻辑代码，应该按照你所设定的规则行事，这个规则就是这个程序的法律，如果超越了这个法律，那么你的代码就应该被修改。当按照这种方法工作的时候，你就会感到快乐。因为，一切都按照你所设想的良性运行。

总结三

抽象系统设计是介于产品需求分析和架构设计阶段之间行为。这个阶段也应该是最快乐的时候。因为你可以自由的制定理性的系统模型，创造性的设定一些巧妙的机关线路，让程序优雅的运行。

我尝试过在开发过程中使用721原则进行。所谓721原则，指的是，70%的精力放在抽象系统设计中，20%精力放在架构设计中，10%的精力放在具体实现中。请注意，我所使用的单位并非时间，而是精力。因为在实际操作中，很有可能你的时间耗费在一些关键问题的处理中或者需求反复变更中。而每一次变更都需要重序这个721原则的三个过程。所以，看上去721原则可以和开发时间相对应，但事实上10%的开发时间可能会更久一些。

为了说明怎么去设计抽象系统，我会在以后的文章中使用这种方法来讲解游戏中不同模块的设计方法。