小议设计模式

好多程序猿案头都有本书叫《设计模式》或者《XX设计模式》，我没有，我有着深深的自卑感，因为我是个半吊子，硬件没做好，软件也是半路出家，认为自己的智商看不懂算法啊、架构啊神马的，所以一直没敢碰这类东西，就是被逼着捋起袖子来开干了，干了好几年，最近总算有胆量想想是不是该提高一下了，恰好在做的项目有些设计思路，又怕是个野路子打法，不足以撑起项目骨架，于是狠研究了一番设计模式，有些感触。

如果入行的时候好好学习一下设计模式就不会走那么多弯路了，23种模式基本涵盖了编程所使用的设计方法，总结的很到位，GoF了不起，但总觉得哪里不对劲，细想之下，其并不是创新和发明，不是学习了就能大杀四方，万军丛中取敌首级的绝世武功，而只是一种方法总结归纳，帮助程序猿更快更好的设计程序、优化结构，方便在一致的认识水平上交流经验。

设计模式之于程序语言，就好比文章体裁之于文字，文章体裁有记叙文、说明文、议论文等，我们小学初中的时候都有写作文的经历，老师会教一些关于文章体裁的知识，告诉我们记叙文的结构是什么样的，分哪几部分，每部分主要写些什么，怎么开头，怎么结尾，那时候，我觉得我是很反感的，写作文就是写作文，为什么要强行规定怎么写呢，我愿意怎么写就怎么写，那多畅快，虽然按照老师教的方法写起来结构清晰，目的明确，易读易理解。现在我并不排斥体裁分类了，但在我写本文的时候并未考虑这是一篇说明文还是记叙文，我只是按照自己的想法来写，老师教的方法已经融入其中，我已不去想它而已。

那么设计模式也是这样的，编程初学是要学的，可以努力去理解，在编程过程中多思考，仔细研究使用设计模式，但重点是不能滥用，不能写个printf还要套个模式，所有单个对象都用单例模式来编写，其结果是出了个编程界的八股文，简单的事情反而复杂化了，设计模式本身的价值就是结构清晰化合易读性上，滥用反而会起到反效果。

我们最终的目的是运用设计模式来更好的解决问题，不是仅仅为了在设计过程中应用上了某某设计模式，我在不了解设计模式之前实际上已经用到了一些设计模式方法，没学过记叙文写作方法就写不了记叙文么？因此，我觉得运用设计模式的最高境界是"眼中有码而心中无码"。当你不再去想设计模式而是拿到一个软件任务，分析出一种实现方法正好符合某某模式。

我觉得设计模式更适合于重构的时候使用，在设计前期就把设计结构想好，并且能够应付设计过程中的功能添加和不断的迭代是不现实的，还有很重要的一点，尤其在国内，往往没有设计前期这一说，为了及时响应客户或者占据市场有利地形，上来就得捋起袖子干了，还深思熟虑啥架构、模式神马的，这时候良好的设计模式训练会在潜意识里帮助程序猿快速找到一个不那么丑陋的设计思路，而更大的设计模式应用之地都在重构过程中了。

总结，需要学习设计模式，但不能盲目的到处使用，要理解并融会贯通，实际的项目也不是一两个设计模式就能搞定的。在实际项目中为了效率和成本可能还要放弃代码的可读性和扩展性，而选择丑类却高效的方法。设计模式并不是灵丹妙药，并不能提高代码执行效率，其主要贡献是提升代码的可读性、可兼容性和扩展性，方便调试、排错、部署、维护和升级。