关于对设计模式与代码规范的…

原文地址：关于对设计模式与代码规范的理解 作者：葱烧烙饼

不知不觉又一个月过去了，也临近项目封测时间了。今天休息一天，好好睡了不知道十几个小时，起来发觉天气正好，下个面吃打开豆瓣FM开始写些觉得稍有意义的东西。同时也为记录这段时间自己的想法。很可能一年后两年后我的想法又不一样了，届时再写下来记录看看变化也是很有趣的事情。

好些人问我：

先学什么样的设计模式？

开发游戏经常会用到什么样的设计模式？

用和不用有什么区别？

事实上，说白了设计模式其实就是面向对象编程的经验。它是 众多程序员长时间实践和思考得到的通用规律。

两三年前，我写代码是不会去考虑该套用什么样的设计模式来实现什么的东西。那时候我对设计模式的概念仅仅停留在《head frist》、《菜鸟设计模式》等书介绍中。即便看完这些书，我还是不觉得设计模式有效和有用之处。游戏项目涵盖面和流程线之长，是无法用几种设计模式来达到的。很多时候都会被某些需要特定的操作打断了你先前的设计。开发人员的素质参差不齐也是一个重要的原因，你写的代码别人若没有理解你的设计意图，在他DEBUG或相应接入的时候，也会把你先前的设计给打乱。

例如最简单的单例模式，基本上即便没有看过设计模式相关书的人都知道单例模式怎么搞。但对于单例的创建和释放这里也有一定的讲究，并不是单例就可以一直占用着内存。若单例中引用了某些资源，单例不释放的话这些资源也不会被释放，占用内存就非常多了。还有就是，一个项目也不可能只有一个单例，几十个单例都是正常。那么我们该用什么方式给单例模式封装成一个接口？这又不仅仅是"单例模式"能够解决的问题了。

并不是所有代码都需要用设计模式，也不是所有代码都要用面向对象的思想去写。有很多情况，面向过程的方法实现某些功能要比面向对象的思想更要快捷好用，清晰易懂，容易扩展。

所以这么说，设计模式不是说学了就直接可以套用上的。根据实际情况需要对模式进行修正和调整，但修正调整后可能就不是原先那个你想的设计模式了。所谓 功夫有招式，临场实战却一定是灵活应变。

别想先学什么样的设计模式，来来去去就那么点内容还什么先学后学，买两本书，从头看到尾也就是那么几天的事情，几天能让你的开发思路有非常大的转变和提高，又何乐而不为？如果你这都不愿意，那么我直接说，看完这些东西，习惯了这些东西那么你的能力至少会让你的工资翻一倍。How do u feel？

设计模式没有什么用和不用的概念。你写代码写到一定程度（N年）即便你没有看过什么设计模式，那么你写出来的都是有一定设计模式的思想在里面的。因为设计模式就是 面向对象的基础（抽象、封装、继承和多态），当这些东西熟练之后自然就写出了这样的东西。

那么我 为什么要去看设计模式的书？既然以后我都会写出来这样的代码……

好比别人告诉你。

“前面有个看不见的粪坑，你走过去会掉下去的，注意一下。”

如果没有人告诉你，你觉得你能绕过这个坑么？当然你掉下去后你也知道了这里有个坑，你以后也不会往下跳了。那么你想沾得满身粪臭么？

不过还真有人，即便告诉他前面有个坑他也会往下跳。即便他爬起来，下次再走这条路，他还是会往下跳。

别人N年总结出来的东西，我们还是去学一下比较好。不然又在浪费生命了。

开发的时候，若没有什么以往的经验，最好就是遵循设计原则和要素。大体来说主要也是几条，我也不多说了，我觉得书上和网上的比我写的好。简单的话可以看看百度百科的设计原则和要素部分。

http://baike.baidu.com/view/66964.htm

实际开发中，即便开始制定了，也很多人随意在写代码或许他们并不那么想，因为项目时间赶，而没有去好好的设计，总想着怎么快怎么弄，先实现了，后面再想办法重构。那么这个时候就需要有一些硬性指标来规范这些代码了。

因为在遵循代码规范的同时，已经限定了设计模式的思想了，即便他们不知道，写出来的或许代码就是之后想要的代码。

编码规范真那么有用？

必然有用，而且非常重要。

例如规范每个函数不能写很长（30行内），那么就会迫使程序员去对长的函数进行功能性的拆分。让函数尽量保持单一功能。

再如规范判断条件的写法，也能迫使程序员去让函数保持单一，而且对条件进行封装。避免否定条件能让代码更加容易看懂。封装边界条件也一样。

如：if(shouldBeDeleted(timer))

要好于:if(time.hasExpired() && !timer.isRecurrent())

若暂时没有对项目好好规范的建议，规范就参照《代码整洁之道》吧，去整理一下适合自己项目的。

暂时来说我们用的项目规范不能公开。

大家多去看看书吧。