设计模式的基础

1.1  设计模式是什么

1.1.1  什么是模式

从字面上来看，模，就是模型、模板的意思；式，就是方式、方法的意思。综合起来，所谓模式就是：可以作为模型或模板的方式或方法。再简单点说就是可以作为样板的方式或方法，类似于大家所熟悉的范例。

1.1.2  设计模式的概念

按照上面的理解，设计模式指的就是设计方面的模板，也即设计方面的方式或方法。

1、设计模式是解决方案

根据上面对设计模式的定义可以看出，归根结底，设计模式就是一些解决方案。

所谓解决方案，就是解决办法，亦即是解决问题的方式或方法。通常所说的方案书，就是把解决方法文档化后形成的文档。

那么，能不能反过来说：解决方案就是设计模式呢？很明显是不行的。为什么呢？因为在解决方案之前还有一些定语，只有满足这些条件的解决方案才被称为设计模式。

2、设计模式是特定问题的解决方案

为什么要限制设计模式是"特定问题"的解决方案呢？

限制"特定问题"，说明设计模式不是什么万能灵药，并不是什么问题都能解决，通常一个设计模式仅仅解决某个或某些特定的问题，并不能包治百病。

因此不要迷信设计模式，也不要泛滥使用设计模式，设计模式解决不了那么多问题，它只是解决"特定问题"的解决方案。

3、设计模式是重复出现的、特定问题的解决方案

那么为何要这些特定问题是"重复出现"的呢？

只有这些特定问题"重复出现"，那么为这些问题总结解决方案才是有意义的行为。因为只有总结了这些问题的解决方案，当这些问题再次出现的时候，就可以复用这些解决方案，而不用从头来寻求解决办法了。

4、设计模式是用于解决在特定环境下、重复出现的、特定问题的解决方案

为什么要限制在"特定环境下"呢？

任何问题的出现都是有场景的，不能脱离环境去讨论对问题的解决办法，因为不同环境下，就算是相同的问题，解决办法也不一定是一样的。

5、设计模式是经过验证的，用于解决在特定环境下、重复出现的、特定问题的解决方案为又什么要限制是"经过验证的"呢？

每个人都可以总结一些用于解决在特定环境下、重复出现的、特定问题的解决方案，但并不是每个人总结的解决方案都算得上是设计模式，这些解决方案应该要有足够的应用来验证，并得到大家的认可和公认。只有经过验证的解决方案才算得上是设计模式。

没有得到验证的解决方案，假如也算设计模式而被大家大量复用的话，万一这个方案有问题呢？那么所有应用它的地方都会出错，都应该修改，这种复用还不如不用呢。

6、为何要强调"在软件开发中"

原因很简单，因为接下来要讨论的内容，就是软件开发中的设计模式，因此这里限制"在软件开发中"。

1.1.3  设计模式的理解

通过上面对设计模式概念的讲述，可以看出，设计模式也没有什么神奇之处，下面对设计模式再做几点说明，使读者进一步理解它。

设计模式是解决某些问题的办法。

要理解和掌握设计模式，其重心就在于对这些办法的理解和掌握，然后进一步深化到这些办法所体现的思想层面上，将设计模式所体现的思考方式进行吸收和消化，融入到自己的思维中。

设计模式不是凭空想象出来的，是经验的积累和总结。

从理论上来说，设计模式并不一定是最优秀的解决方案，有可能存在比设计模式更优秀的解决方案，也就是说设计模式是相对优秀的，没有最优，只有更优。

这也说明，从理论上，我们自己也可以总结一些这样的解决方案，如果能得到大家的认可和验证，也是有可能成为公认的设计模式的。

设计模式并不是一成不变的，而是在不断发展中。

本书仅仅讨论GoF的著作中所记载的、经典的设计模式，但并不是说只有这些设计模式。因为设计模式的发展从设计模式引入软件中以来，就从来没有停止过。

设计模式并不是软件行业独有的，各行各业都有自己的设计模式。

用大家身边的例子来说，比如医药行业，就有自己的设计模式。假设一个人感

冒了，到药店买感冒药，这个感冒药就是设计模式的一个很好体现。

经过验证的：药品上市前，会有大量的验证和实验，以保证药品的安全性。

特定环境下：这些药品是针对人的，不是针对其他动物的。

重复出现的：正是因为感冒会重复出现，研制药品才是有意义的。

特定问题：感冒药只是用来解决感冒问题的，不能解决其他问题，比如脚痛。

解决方案：药品本身就是该解决方案的具体体现。

经过上面的比较，你会发现，医药行业对设计模式的体现，一点也不逊色于软件行业。再说设计模式本身不是起源于软件行业，而是起源于建筑业。





1.1.4  设计模式的历史

设计模式起源于建筑行业，一位名叫Alexander的建筑师发现并总结了一些建筑行业的设计模式。

在20世纪90年代，准确地说是1995年，由于Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides合著的《设计模式--可复用面向对象软件的基础》一书的出版，正式掀开了软件业设计模式的序幕，这本书的四位作者被世人称为四人组，也有人将其称为"四人帮"，也就是大家常见的GoF（Gang of Four）。


1.2  设计模式有什么

1.2.1  设计模式的组成

在描述单个设计模式的时候，设计模式通常由以下部分组成。

模式名称：就是为每个设计模式取的名字，应好记忆，也好交流。

环境和问题：描述在什么场景下，出现什么样的特定的问题。

解决方案：描述如何解决这个问题。

效果：描述模式应用的效果，以及可能带来的问题，或者使用中需要权衡的问题。

在Java领域，对于设计模式的组成还有另外一种分法，就是按照设计模式所在的技术领域来划分，大致分为以下几类。

Java设计模式：通常指GoF的《设计模式--可复用面向对象软件的基础》一书中提到的设计模式。

JavaEE设计模式：通常指SUN《J2EE核心设计模式》一书中提到的设计模式。

其他领域的，包括但不限于：EJB设计模式、实时系统设计模式、多线程设计模式、架构模式等。

1.2.2  设计模式的分类

为了缩小范围，我们仅讨论Java设计模式，也就是GoF著作中提到的23个设计模式。对于这23个设计模式，GoF把它们分为三类。

创建型模式：抽象了对象实例化的过程，用来帮助创建对象的实例。

结构型模式：描述如何组合类和对象以获得更大的结构。

行为型模式：描述算法和对象间职责的分配。
当然也有按其他方式进行分类的，这里就不再讨论了。

1.3  设计模式的学习

1.3.1  为什么要学习设计模式

为什么要学习设计模式？实在是有太多的理由了，这里简单地罗列几点。

1、设计模式已经成为软件开发人员的"标准词汇"

很多软件开发人员在相互交流的时候，只是使用设计模式的名称，而不深入说明其具体内容。就如同我们在汉语里面使用成语一样，当你在交流中使用一个成语的时候，是不会去讲述这个成语背后的故事的。

举个例子来说：开发人员A碰到了一个问题，然后与开发人员B讨论，开发人员B可能会支招：使用"XXX模式"（XXX是某个设计模式的名称）就可以了。如果这个时候开发人员A不懂设计模式，那他们就无法交流。

因此，一个合格的软件开发人员，必须掌握设计模式这个"标准词汇"。

2、学习设计模式是个人技术能力提高的捷径

设计模式是很多前辈经验的积累，大都是一些相对优秀的解决方案，很多问题都是典型的、有代表性的问题。

学习设计模式，可以学习到众多前辈的经验，吸收和领会他们的设计思想，掌握他们解决问题的方法，就相当于站在这些巨人的肩膀上，可以让我们个人的技术能力得到快速的提升。学习设计模式虽然有一定的困难，但绝对是快速提高个人技术能力的捷径。

3、不用重复设计

设计模式是解决某些特定问题的解决方案。当我们再次面对这些问题的时候，就不用自己从头来解决这些问题，复用这些方案即可。

大多数情况下，这或许是比自己从头来解决这些问题更好的方案。一是你未必能找到比设计模式更优秀的解决方案；另外通过使用设计模式可以节省大量的时间，你可以把节省的时间花在其他更需要解决的问题上。

1.3.2  学习设计模式的层次

学习设计模式大致有以下三个层次。

1、基本入门级

要求能够正确理解和掌握每个设计模式的基本知识，能够识别在什么场景下、出现了什么样的问题、采用何种方案来解决它，并能够在实际的程序设计和开发中套用相应的设计模式。

2、基本掌握级

除了具备基本入门级的要求外，还要求能够结合实际应用的场景，对设计模式进行变形使用。

事实上，在实际开发中，经常会碰到与标准模式的应用场景有一些不一样的情况，此时要合理地使用设计模式，就需要对它们做适当的变形，而不是僵硬地套用了。当然进行变形的前提是要能准确深入地理解和把握设计模式的本质，万变不离其宗，只有把握住本质，才能够确保正确变形使用而不是误用。

3、深入理解和掌握级

除了具备基本掌握级的要求外，更主要的是：

要从思想上和方法上吸收设计模式的精髓，并融入到自己的思路中，在进行软件的分析和设计的时候，能随意地、自然而然的地应用，就如同自己思维的一部分。

比较复杂的应用中，当解决某个问题的时候，很可能不是单一应用某一个设计模式，而是综合应用很多设计模式。例如，结合某个具体的情况，可能需要把模式A进行简化，然后结合模式B的一部分，再组合应用变形的模式C…，如此来解决实际问题。

更复杂的是除了考虑这些设计模式外，还可能需要考虑系统整体的体系结构、实际功能的实现、与已有功能的结合等。这就要求在应用设计模式的时候，不拘泥于设计模式本身，而是从思想和方法的层面进行应用。

简单点说，基本入门级就是套用使用，相当于能够依葫芦画瓢，很机械；基本掌握级就是能变形使用，比基本入门级灵活一些，可以适当变形使用；深入理解和掌握级才算是真正将设计模式的精髓吸收了，是从思想和方法的层面去理解和掌握设计模式，就犹如练习武功到最高境界， "无招胜有招"了。要想达到这个境界，没有足够的开发和设计经验，没有足够深入的思考，是不太可能达到的。

有些朋友说：设计模式的书我看了不少，觉得都看懂了，就是不知道在实际开发中怎么用这些设计模式，于是他们认为设计模式是"看上去很美"的"花拳绣腿"。其实这些朋友正处于"设计模式了解级"，根本还没有入门。

1.3.3  如何学习设计模式

结合作者自身的经验，给出以下学习设计模式的建议。

（1）首先要调整好心态，不要指望一蹴而就，不可浮躁。

学习和掌握设计模式需要一个过程，不同的阶段看这些设计模式会有不同的领悟和感受。

不要指望真正的设计模式的书籍是既简单又有趣的，一看就懂的。那种书籍多是属于科普性质的书籍，只是让你简单了解一下设计模式。这也是为何很多朋友总感觉"懂"设计模式，却不会在实际项目中应用设计模式。那是为你"懂"的程度不够。

要想真正理解和掌握，必须要上升到一定的难度和深度，让你看完后思考，思考后应用，然后再看、再思考、再应用，如此反复，方能成就。

"鱼和熊掌不可兼得"，因此，本书尽量在内容的深度、难度和讲述的通俗易懂、简单明了上进行均衡，以期大家能以较小的力气去真正理解和掌握设计模式。

（2）学习设计模式的第一步：准确理解每个设计模式的功能、基本结构、标准实现，了解适合使用它的场景以及使用的效果

（3）学习设计模式的第二步：实际的开发中，尝试着使用这些设计模式，并反复思考和总结是否使用得当，是否需要做一些变化。

（4）学习设计模式的第三步：再回头去看设计模式的理论，有了实际的模式应用经验再看设计模式，会有不同的感悟，一边看一边结合着应用经验来思考。比如：设计模式的本质功能是什么？它是如何实现的？这种实现方式还可以在什么地方应用？如何才能把这个设计模式和具体的应用结合起来？这个设计模式设计的出发点是什么？等等。可以有很多考虑的点，从不同的度对设计模式进行思考。

（5第四步：多次重复学习设计模式的第二步和第三步。也就是在实际开发中使用，然后结合理论思考，然后再应用，再思考……多次，直到达到对设计模式基本掌握的水平。

简而言之，大家要注意使设计模式的理论和实践相结合，理论指导实践，实践反过来加深对理论的理解，如此反复循环，成螺旋式上升。

事实上，到了基本掌握设计模式的水平后，最后能达到一个什么样的高度，因人而异，需要看个人的思维水平和理解水平。对于这个阶段，只有一个建议，那就是反复地、深入地思考，别无它法。到了思想的层面，就得靠"悟"了。