软件浅谈（二）：喧嚣的设计模式

这个题目我想了很久，最后还是决定用喧嚣这个词。的确，如果把业界比作一个市场，“设计模式”必然会是充斥在耳边最频繁的叫卖声。

到底设计模式是什么，这是每一个做过一段时间代码的人都会迎面撞上的问题。记得我在做代码之初曾有一个伙计一脸牛气的告诉我，某个模块他用了工厂模式，当时我的反应就是：啥？你去工厂里摸啥了？！

后来我怀着劫富济贫的心情去探究了一番，想弄明白这个可以拿过来像iphone一样炫耀的东西到底是什么。众说纷纭中，让我至今记忆犹新的，还是Martin Fowler所说的：一个模式，就是在某个实际的上下文中有用，并且可能在其他上下文中依旧有用的想法。说的再通俗一点：设计模式，就是一个可以被重复拿来使用的解决相似问题的方式。

记得当时在认识到这点之后，自己的身影就在心中伟岸了起来。那时的我打从心底里看不上用设计模式的人，说到底，你是在用别人的办法解决问题，而我却是在创造自己的模式！某天早上起床时灵机一动，一个困扰了一晚的问题突然有了搞定的办法，于是我就决定要用它创造出了一个“起床模式”！

但好景不长，就像用着谷phone(iphone的山寨机)的人最终会发现手里这个不知道拿着一堆神马东西拼凑的所谓神机，并不能像iphone一样较好的解决你的实际需求一样，“起床模式”也会不断地去刺激你的神经。它会随着一次次的重用时的修改变得越来越臃肿和凌乱，最终差点成为“躺枪模式”。

唯一让我觉得欣慰的，还是我自己的受虐能力。我咬紧牙关在无数个漫漫长夜中一次次的审视和重构我的“起床模式”，最后还真让我磨出了一个可用的模块设计。

沾沾自喜？我想这最能形容我当时的心情，直到好友见到这个模块的设计后惊讶道：嗯？你也开始用设计模式了？我慌乱的翻出一本设计模式，然后浏览着其中的各种模式描述，最终发现了Iterator。我耗费了大量时间和精力折腾出的“起床模式”竟然仅仅是形似Iterator的一种设计！

爬上巨人的肩膀才能更容易的高过巨人，当你自己做过很多代码的重构和模块的设计之后便会发现，已经被整理出的设计模式大都是某一类问题当前最佳的解决方案，另辟蹊径，最终也大多会万流归宗。因而，设计模式是软件探索旅程中的一个不错的指南针，可以避免你在前行的路上绕来绕去后才最终发现，原来早有人在这段路上插下了路标、指明了方向。

忘记了哪本书上曾说过，接触设计模式的人会有三个阶段：茫然不知，毫不了解什么是设计模式；奉为圣经，开口闭口必然设计模式；淡忘模式，使用起来随心所欲，最终甚至遗忘了自己所用的模式的名称。

很遗憾的是，前两个阶段我都经历过。尤其是第二个阶段，让我深刻的体会到了什么叫过犹不及，不，应该说，对于软件开发，过尤甚于不及。明显的过度设计（过度设计并不好界定，有的时候形似过度设计，但随着突然产生的需求变更可能反而会成为有前瞻性的优秀设计，但是明显的过度设计就是一种错误了）是最常见的产物，它消耗了大量的时间，扭曲了原本简单的需求，仅仅是为了能套用一个模式去实现，然后牛气地告诉别人：嘿，伙计，我去工厂摸那个啥来。。。。。。所以，一旦有人这样告诉你，你就可以淡定的敲着自己的代码，顺便告诉他：please继续摸。

当一个人能将模式信手拈来的时候，他就会把模式作为一种最普通的常识，是一个交流时的精简的通用语，就像没人会跟你说：嘿，伙计，今天地球是圆的一样，他也不会告诉你自己今天又摸了什么。

当然，我们也没有必要像书里说的那样，最终连模式的名称都忘掉。正像我前面所说，它是一个包含了丰富的内容，非常简洁又没有歧义的交流时的通用语，可以极好的降低交流所耗费的时间和歧义。毕竟，在团队开发中，交流成本也是需要控制的一种昂贵的成本，当然，这是题外话了。

最后，虽然能熟练的使用设计模式可以让你轻松的写出让人感觉舒适的优美的代码，但是在浩大的软件工程体系面前依旧是刚刚起步。若用建筑工程来类比，就恰似一片别墅区内一座别墅后院的花坛设计师，或者苏州园林里无数亭榭廊坊中的一个长廊一隅的结构设计师。我们依旧需要扣问：路在何方——