这个帖子是很久以前发在我的上一个blog上了。回头看一看，其实有不少地方，都有了新的东西。
原来的帖子有些偏激，也有些罗嗦，但是总的来说，由于我的进步没有那么大，也就没看出那么多的问题。
所以仍然原帖发过来。如果有任何不同的见解，欢迎砸砖。
------------------------------------------------------------------------------------------------------------------------
本文是写给那些希望设计游戏引擎，但是有经常写出Big mud ball代码的朋友们。
如果你的技术不是很好，或者没有任何设计经验，那么这篇文章就是为你而写的；
如果你拥有不错的技术，或者有一定的设计经验，我希望能与你交流，共同探讨开发；
如果你很牛气，那么充满困惑和疑问的我真心的能够希望得到您的指点。
由于篇幅限制，一些参考书上已经有很详细的讲解的，我就不写了，书上讲的比我写的要好多了。
由于我还在学习中，因此我便只写那些我了解并已经使用了的部分。如果您发现本文的错误或者不可行的地方，请您能留下您宝贵的意见，谢谢。
开篇
有关设计模式的参考书目，我想我不用多说了。经典的Design Patterns是必备的，其它的书，我会在引用到的时候再讲。其实我看的也很少。
Design Patterns 的书在开始的部分就说明了，这些模式并不一定适合分布式或者实时领域。但是，当阅读专门讲述有关实时领域的模式的时候，你仍然会发现，这23个设计模式依然能够放出夺目的光芒。这充分说明了，一种好的设计，它的生命的价值不在于一行行代码，而在于这些代码后的智慧。因为它是智慧，所以我们在使用的时候就不能一成不变的去使用它，而是应该吃透其中的精髓，将它的内涵演化到我们自己的设计中。
一个良好的设计不是一蹴而就的，至少对于新手是如此。编程才华往往会比设计才华早很多年的时候就被发现，因为设计是需要经验的。对于我这样的新手来说，往往会缺乏做出抉择的勇气和经验。但是事实证明，只要我们做了，结果一般比我们想象的都要好。我们不能因为追求一种本来并不需要的灵活度，而去使用一些将软件搞得更复杂的设计。必须要记住，软件越复杂，我们便越难成功。
所以做软件不要太纸上谈兵。如果你拿捏不准一样设计是好是坏，那么你就去做出来。当然我并不是说要全部做出来，而是要做出一个合适规模的DEMO，然后去考察它能否满足要求。如果满足了，那么请你一定要拒绝“更好的设计”的诱惑，一旦你不幸坠落深渊，那么可能就再也爬不起来了。
所以，再你使用任何一项设计前，
请————
分析 - 判断 - 编写 - 测试 - 验证
然后重构你的DEMO，看看有没有可能直接就纳入到项目之中。当然不要太认死理，我相信你一定能在一个下午之内摆平你曾经写过的2000行代码。当然，要有测试的保证。
学了面向对象以后，不能将结构化设计给忘了。结构化对于一个流水线一样的作业过程，是有着它独特的优势的。这种作业方式在游戏程序里面并不少见。所以，设计被决定的原则是：最合适的就是最好的。这里的适合有多种评判标准，例如你的经验，技术，成本，问题本身的特征等等。
ok，我上面说了那么多的废话，只是想说明一点的就是：合理的使用模式，没有什么东西可以被滥用而不造成危害。
（未完待续）