设计模式之无招胜有招

模式之无招胜有招"/>

设计模式之无招胜有招

GOF设计模式从出版(1995)到今天(2016)过去21年了。

21年过去了，设计模式仍然是计算机领域的高精尖技术。这是因为设计模式在很高的抽象级别上抓住了设计的本质，而这个本质在近三十年没有改变，在可预计的十年内也仍然不会发生变化。作为一个程序员学习设计模式这种高精尖技术是程序员之路突破的必经之路，也是改善程序员日常工作生活的一个利器，更是对程序员是吃青春饭的行业的结论的有力回击。

可以这么说设计模式是程序员进阶必备。

设计模式为何如此神奇呢？首先是由计算机发展历史决定的。在计算机诞生初期，计算机是真正的高大圣，计算机的价格更是高大圣。那是个计算机硬件比人贵的岁月，因此CPU,内存是那个年代考虑的非常重要的因素。什么代码可读性啊，可维护性啊，统统让位于性能。因此你在翻阅那个年代的书籍和影视资料的时候发现，代码如何简短高效是第一考虑因素。简短高效往往带来代码的含混不清，因此那个时候你能写别人看不懂的代码，会被当做高手的。这个规则在今天依然能看到他的痕迹。

当今时代是计算机“飞入寻常百姓家”的时代。计算机的硬件成本急速降低。且随着计算机向各个行业的渗透(互联网+就是例子)，系统越来越庞大复杂。市场竞争也越来越激烈，如何在庞大复杂的系统里面在更短时间以更低成本推出新的产品功能成为计算机行业的一个焦点。设计模式在一定程度上回答解决了这些问题，因此设计模式成为并且仍然是计算机学科的高端技术。

再次，设计模式主要是面向对象的设计模式。面向对象的语言从诞生到现在依然有旺盛的生命力。只要面向对象的语言如C++和JAVA不死亡，设计模式就不会死亡。

从以上我们可以看出行业发展的本质对设计模式的决定性影响。下面我们将从设计模式角度仔细讲解这些本质问题，以及设计模式是如何解决这个本质问题的。

设计模式是英文design pattern的翻译。 pattern这个词很抽象，我在很长时间里面对pattern模式这个词觉得困惑。直到某一天，我听到一个本地化的翻译“设计套路”，我一下子豁朗开来。模式就是套路。就像是武侠小说里面的武功一样。降龙十八掌，太祖长拳等等。每个武功都是套路。GOF设计模式书中提到的23种设计模式就是23个套路，23个招式。

23个招式学会了，你就能在武林抖擞抖擞了。

但是如何成为武林顶尖高手呢？仅仅学会23招式远远不够的。

在一份对金庸武功排行榜上，独孤九剑排名第一。

为啥呢？其他武功都是讲究套路，唯有独孤九剑是谈到了很高的哲学抽象。“无招胜有招”。

设计模式的23个模式也只是23个招式，如果你只会死记硬背23个招式，在武林中也就是中游水平。如果你能学会设计模式的“无招”，那么你就是顶尖高手了。

本文就是想探讨一下设计模式的“无招”。独孤九剑没有招式，但是有个总诀，就是风清扬让令狐冲背诵的破剑式，破刀式等等。独孤九剑还有一个理念“看清破绽，后发制人”。

设计模式也有隐藏在23个招式后面的一个总诀，那是一系列的设计原则和原理方法。同样设计模式也有他的理念“refactor to pattern”，模式是随着软件的变化而逐渐形成的，很多时候不需要你提前说我要用什么模式。随着软件的发展，你看清楚软件的演进变化方向，再后发制人，用模式来改进你的代码。

总结一下上面的话：设计模式可以理解为设计套路。是针对于某些特定问题的套用。当看到类似问题的时候，就直接往上套用。但是套用是低水平的应用，想要顶尖的话还是要理解这些套路为什么能很好解决这些遇到的问题。就是要知道设计目的，设计的原则，设计的原理和方法，设计的语言层面的支持。

GOF书上对设计模式的定义为：针对于一再出现的重复性问题的较好的解决方案。那么我把定义扩充一下：面向对象的设计模式就是指在面向对象程序设计过程中，基于面向对象设计语言提供的语言技术，按照一定的设计原则和设计方法设计出来的满足特定目的的设计。

总诀里面的“无招”就是要理解设计目的，设计原则，设计方法，设计技术以及设计原理。这些是所有23个招式的灵魂。当你有了这些总诀，你可以随意演绎23个招式，可以把他们合并，可以把他们扩展，可以开发新的模式。我们要做的就是融会贯通。

一般的设计模式的书上直接就讲23个招式，不讲前面的总诀。就像胡斐拿到了刀法的下册，打起来总是觉得不明白。

首先我们平时说的设计模式指的是面向对象的设计模式。根据设计模式或者套路的定义，他可以使用在任何地方。但是这里狭义的指面向对象的程序设计。尤其是指C++，JAVA等类似的语言。后面会讲述封装，继承和多态。

其次，设计目的。之所以能够把23中模式提炼出来是和设计目的密不可分的。当你接到一个需求，要用面向对象的设计语言实现一个产品的时候，你可以有多种方案多个选择。怎么决定哪个方案最好？和你的目的相关。一般来讲，设计目的包括了功能正确定，性能，可移植性，可读性，可扩展性，健壮性等。大部分的设计模式是和可扩展性息息相关的。

再次，设计原理，这部分是核心中的核心。

有些设计模式比较单纯，如单例模式就是讲如何用面向对象的设计语言技术保证产品中有且只有一个对象实例。

大部分的设计模式还是和可扩展性相关的。可扩展性是指当你的产品发生变化，代码需要变动的时候，只需要添加新的类，而无需改动已有的类。

这里提到了“改变”，改变是大部分设计模式存在的前提理由。正式因为有了改变，我们才需要在改变发生的时候，设计出一系列套路使得改变对代码冲击最小。最理想的是改变来了，我什么都不要代码变动。这个基本上是天方夜谭，几乎不存在。次一个级别的就是，当改变来的时候，我只需要修改配置文件。这个需要一个良好的设计框架，在现实中也存在，你的代码可能不需要编译链接部署。再次就是当改变来的时候，我不需要修改已有代码，只需要加入新的代码新的类，需要重新编译链接部署等等。这已经是非常好的设计了。我们的很多设计模式都能达到后面两种的效果。

那么是如何实现的呢？我们先看一个例子。产品中有A和B两个类，且A使用了B中的代码。现在改变来了，B的方法变了，那么A也会受到波动和冲击。这是因为A和B之间的依赖性太强了。如何去除或者减弱A和B之间的依赖，使得当B改变的时候A不收影响呢？这个就是设计模式研究的一个最简模型。解耦，解除A和B之间的耦合性。

后文中会有大量的文字用到改变，依赖性，耦合。这里把他们统一起来。当提到解耦合的时候，也就是说去依赖，使得系统更好应对改变的冲击。

那么如何解耦合呢？在语言层面就是要使用多态。用粗话说，多态使得我们拥有“函数signature不变，但是函数功能改变”的能力。也就是说如果A中调用了B的一个函数，那么只要函数的signature不变，我们可以另外实现该函数的功能，使得当B扩展新功能的时候，对A没有影响。  这个是语法侧面上的解耦合。

那么如何寻找到这个函数呢？有一些列的设计的方法。这里指的是一些如何实现解耦合的手段。封装变化，优先使用组合，针对接口编程，抽象，松耦合。

在使用这些方法的时候还有一些原则，如SRP,OCP,DIP,LSP等。遵循这些原则，设计出来的对象松耦合高内聚，弱依赖性。

后面的23中设计模式就是在这些基础上，针对不同的情景和面对的问题，总结出来的套路。

要想学好套路，先要学会总诀。无招胜有招。