浅谈对设计模式的自我理解

       中国人有不破不立的思维，远的如秦始皇焚书坑儒、项羽火烧阿房宫，近的如破“四旧”。正是由于有了这样的思想，于是乎能改的就改，不能改的就推翻重写，没有一个持续开发蓝图。为什么要破才能立呢？为什么不能持续发展？你说这是谁的错呢？是你架构师的错，你不能持续的拥抱变化，这是一个系统最失败的地方。那怎么才能实现拥抱变化的理想呢？设计模式！

       设计模式是什么？他是一套理论，由软件界的先辈们总结出的一套可以反复使用的经验，它可以提高代码的可重用性，增强系统的可维护性，以及解决一些列的复杂问题。做软件的人都知道需求是最难把握的，我们可以分析现有的需求，预测可能发生的变更，但是我们不能控制需求的变更。问题来了，既然需求的变更是不可控的，那如何拥抱幻化呢？幸运的是，设计模式给了我们指导，专家们首先提出了6大设计原则，但这6大设计原则仅仅是一系列的“口号”，真正付诸实施还需要有详尽的指导方法，于是23种设计模式出现了。

         他是软件行业的经验总结，因此他具有更广泛的适应性，不管你是用什么编程语言，不管你遇到什么业务类型，设计模式都可以自由地“侵入”。

          因为他是指导思想，你可以在此基础上自由发挥，甚至可以自己设计出一套设计模式。

          如果你通晓了23种设计模式，你就可以站在一个更更高的层次去赏析程序代码、软件设计、架构，完成从代码工人到架构师的蜕变。

          技术也可以很有乐趣，也可以让你不用皱着眉头思考，等待你的只是静静地看，慢慢地思考，设计模式的内容会润物细无声的融入到你的思维中。我们的设计模式是一把刀，极致的境界就是心中无设计模式代码亦无设计模式——设计模式随处可见，俯拾皆是，已经融入到软件设计的灵魂中，这才是高手中的高手，简称高高手。

           设计模式是编程抽象化的一个具体的应用，它让程序更好的阅读和理解，逻辑上更加合理，是通向更大规模软件的一个基础，换个说法，如果一个软件的模式很混乱那么它混乱到一定的程度就再也编写和维护不下去了，一直觉得Java c＃的设计模式体现得更好，这是因为和他们的一切都是对象的理念比较一致，c＋＋的稍微少一些，但是同样重要。

           至于什么是设计模式，他有什么好处等等，不是我今天要说。我想举个例子，做个对比。我们都知道，设计模式源于建筑领域，建筑领域可能离我们太远，我今天想拿篮球运动做个对比。

           篮球运动员为了提高篮球水平，除了进行身体训练和投篮训练外，还会进行一些连贯动作的训练和一些战术配合训练。比如，像交叉步，急停跳投，转身过人，挡拆等等。这些训练是从何而来？篮球运动刚刚诞生的时候肯定没有。而是运动员在篮球运动过程中，发现在某一种情况下（也就是防守队员和团队成员的位置），使用某一中类似的连贯动作往往能够取到非常好的效果。所以就有悟性非常高的人把这种约束条件和要采取的动作都总结出来，让运动员在训练中反复的训练，以形成一种条件反射，在出现合适的机会的时候，快速而有效的使用这些连贯动作。

           我想这也是模式的起源。有一点不同的是，我们学习设计模式的过程，是一种思维训练的过程 。

           不难想象，如果没有这些东西，运动员要提高篮球水平有多困难。但运动员如果在比赛中滥用，花哨的动作也许会增强比赛的观赏性，但是它却偏离了篮球运动的本质：将篮球投进并赢得比赛。

            其实，上面的这些分析对于武术也同样适用。武侠迷可能会记得金庸笔下纷繁复杂招式名称（其实也是模式）。不过，金庸倒也提到过更高的境界：“无招胜有招 ”。印象当中张无忌学习太极拳和令狐冲学习独孤九剑有描述。他们在学成之后确实很厉害。难怪jamie zawinski和Brendan eich会有些反对模式，也许他们已经学到了无招胜有招的真谛，也许他们是黑客，不喜欢思维受到限制。

           难道我们要抛弃所有的模式？不过我认为它可能并不适合所有的人，它依赖于人的造诣，以及天赋，悟性。我们很多人要获得提高，进行一些模式训练，也许还是一条非常有效的途径。

           乱七八糟说了这么多，最后总结一下：

1. 首先要认识到它的本质，模式是前人知识经验的总结，不是现成的解决方案，所以不要硬套。
2. 对于初学者来说，模式是个好东西，学习一些模式是一条有效的提高途径。
3. 不要过度使用设计模式，他会给你带来额外的复杂度。 在我的眼中，简单性才是一个技术方案的首要因素。你知不知道李小龙截拳道的核心是什么？抛开招式，直截了当的进行最有效的攻击和防守。
4. 不要把它当成银弹或者圣杯。
5. 当你有一定的积累后，你也可以尝试“无招胜有招”的境界。