经典设计模式实战演练

课程简介

面向对象的程序应该具有可维护性，代码可复用性，扩展性以及灵活性。为了实现以上目的，前辈们从实践中总结出了一套可套用的武功招式，这就是设计模式。使用设计模式可以让你写出一手令人赏心悦目的代码。

我认为每一个后端开发者都应该学习设计模式，它是代码的精华，是程序发展的强力支撑，是能够让你发出惊叹的神来之笔。

课程主要分为两大部分：

第一部分（第01-09课），介绍常用的几种设计模式，通过具体案例的分析与代码实现带领大家深入学习与理解设计模式；

第二部分（第10课），将结合多种设计模式手把手带领大家开发一个综合案例，提升设计模式实战的能力。

周君，资深后端工程师，CSDN 博客专家，精通 PHP、Java、Web 开发。多年实战经验，热衷分享。

课程内容

导读：如何学好设计模式

0.1 什么是设计模式

设计模式（ Design Pattern ）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长一段时间的试验和错误总结出来的。

上面的解释来自于 络，是比较标准的定义，可以从中筛选出几个关键字来帮助我们理解什么是设计模式：

• 最佳实践
• 解决方案
• 试验和错误总结

从上面的三个关键词中可以总结出，设计模式就是在针对编码过程中遇到的问题总结出来的最佳解决方案。

那么这些问题指的是什么问题呢向对象的程序应该具有可维护性、代码可复用性、扩展性及灵活性，要解决的问题就是代码可维护性问题、复用性问题、扩展性问题及灵活性问题。

简单来说，设计模式就是指导你如何写出可维护、可复用、可扩展及灵活的代码。

0.2 设计模式分类

设计模式总共有 23 种，总体来说可以分为三大类：创建型模式（ Creational Patterns ）、结构型模式（ Structural Patterns ）和行为型模式（ Behavioral Patterns ）。

上面的三种分类说明，有助于在开发时思考当前场景应该使用哪种分类。大家不一定要全部记住，有个大概的了解即可。

0.3 学习设计模式

1. 为什么要学设计模式

写出可维护、可复用、可扩展及灵活的代码是我们的目的，也是学习设计模式的理由，但是这个理由对我们来说太抽象，下面从 “ 读 ” 和 “ 写 ” 两方面来说明到底为什么要学习设计模式。

• 读

作为开发人员，不可避免地要接触其他人写的代码，有的是一些知名的库或框架，例如 Spring 、Shiro 等。但是当我们去阅读这些框架源码的时候会发现无从下手，因为类太多了，关系太复杂，而且很多类的命名看不懂，比如 xxxBuilder 、xxxStrategy 、xxxFilter 等，一个词看不懂就可能导致你直接放弃继续阅读。

如果没有学过设计模式，自然看不懂，学习设计模式可以有效地帮助你阅读代码，即便不能百分百帮到你，至少也能帮到百分之三四十。

• 写

每一个开发人员必然喷过其他人写的代码，觉得其他人的代码有的写得很垃圾，尤其是要扩展功能或者修改功能的时候，恨不得全部删掉重新写，其实在其他人看来你的代码也是如此。所以写出一手让人无话可说的代码是很有必要的，不仅可以满足你的小小成就感，也可以让你的程序更快速稳定地发展。

在一个项目组中，如果大家都学习过设计模式，那么当你阅读或修改同事写的代码时也将得心应手，少了很多麻烦。

2. 如何学好设计模式

如今 上和书上都有大量的设计模式教程，但是他们大部分都有一个共同点：仅仅使用生活中的例子。

比如前几年我第一次学习设计模式，在学到适配器模式时，教程中抛出了一个电器的插头问题：

你家插座只有三头的，但电器插头是两头的，怎么办个插头适配器将两头转换成三头。

Nice，这个例子简单明了，作为新手的我瞬间明白了适配器的含义，就是在不兼容的双方中间做一层转化。但是后来发现在实际编码中根本用不上这个设计模式，因为我不会用。

生活中的例子的确可以帮助我们理解设计模式，这是毋庸置疑的，但是想要真正用好设计模式，实际项目中的案例是必不可少的，这也是我写这门课的原因，希望通过分析实际案例，能够帮到更多想要学习设计模式的同行。

下面给出几点更加具体的建议：

• 从生活例子中去理解设计模式；
• 从实际案例去了解设计模式的使用场景；
• 动手实践，在学完实际案例之后，不妨动手写一写，不要写生活中的例子，自己构造一个小功能，用上你的设计模式；
• 改变自己的意识，在开发或修改一个功能时，首先要下意识地去思考这个功能将来在修改和扩展上会遇到什么问题，能否用上设计模式。记住一定要思考、一定要思考、一定要思考，即便最终用不上，也能让你回顾一遍设计模式的内容，使其知识更牢固。很多开发者不是不会用，而是根本没有想过要用设计模式，久而久之这方面的能力自然就弱化了。

0.4 课程说明

1. 课程内容

本课程每一篇文章都包含三大部分：

• 解释和理解设计模式；
• 至少介绍一个实际案例（ 实际案例有些是我自己写的，有些来自于已有的框架或库 ）；
• 设计模式优缺点。

2. 必要准备

本课程将使用 Java 语言讲解设计模式，虽然设计模式与语言本身无关，但是本课程中有许多实际案例都是来自于知名的 Java 框架源码，如果没有 Java 基础，学习效果可能不佳。

除了要求 Java 基础之外，还需要了解 UML 图，如果不了解 UML，只需要知道以下几种 UML 关系即可：

• 泛化，可以简单地理解为继承关系；
• 实现，一般是接口和实现类之间的关系；
• 关联，一种拥有关系，比如老师类中有学生列表，那么老师类和学生类就是拥有关系；
• 聚合，整体与部分的关系，但是整体和部分是可以分离而独立存在的，如汽车类和轮胎类；
• 组合，整体与部分的关系，但是二者不可分离，分离了就没有意义了，例如，公司类和部门类，没有公司就没有部门；
• 依赖，一种使用关系，例如创建 A 类必须要有 B 类。

参考下图：

从上图可以看到，我们将操作封装到类中，他们实现了同一个接口，然后在 Context 中调用。

这里我们举一个计算器的例子：

代码：

使用：

看完更换主题的案例代码，你会发现跟计算器惊人地相似，没错，所谓设计模式就是前人总结出来的武功套路，经常可以直接套用。当然也要灵活地根据实际情况进行修改，设计模式想要传达给我们的更多的是一种编程思想。

这里还有一个小窍门：

在这里老王 New 一个默认主题对象，如果其他开发者加了主题，还要修改这行代码，New 开发者自定义的主题对象。根据开闭原则，我们不希望其他人修改我们的任何一行代码，否则拔刀相见。老王机智地将主题的包名和类名写到了配置文件中，利用 Java 的反射机制动态生成主题对象，因此更换主题也只要修改配置文件即可。

2. Shiro

Shiro 是 Java 界最著名的权限控制框架之一，相信大家都不陌生。在 Shiro 中，我们可以创建多个权限验证器进行权限验证，如验证器 A、验证器 B、验证器 C，三个验证器可以同时生效。

那么就产生了一个问题，如果验证器 A 验证通过，B 验证不通过，C 验证通过，这种情况怎么办底算当前用户验证通过还是不通过呢/p>

Shiro 给我们提供了三种验证策略，就像老王默认提供了一种主题一样：

• AtLeastOneSuccessfulStrategy ：只要有一个验证通过，那么最终验证结果就是通过。
• FirstSuccessfulStrategy ：只有第一个成功地验证的 Realm 返回的信息将被使用，所有进一步的 Realm 将被忽略，如果没有一个验证成功，则整体尝试失败。
• AllSucessfulStrategy ：所有验证器都必须验证成功。

如果你不熟悉 Shiro ，看不懂上面三种策略的含义，没关系，本课程讲的是设计模式，而不是 Shiro 的使用，你只要知道 Shiro 默认为我们提供了三种策略即可。

作为开发者，在使用 Shiro 的时候，Shiro 默认的策略未必符合我们的需求，比如我们要求三个验证器中通过两个才算通过，怎么办简单，Shiro 这里用的也是策略模式，我们只要自定义一个 MyAuthenticationStrategy 继承 Shiro 的 AbstractAuthenticationStrategy 。咦面不是说实现接口吗，这里怎么是继承通，要懂得变通。设计模式不是一成不变的，重要的是这种编程思想。

然后在 MyAuthenticationStrategy 实现父类要求的方法，再修改配置文件将当前验证策略改为你定义的验证策略：

1.3 课程总结

1. 优点

讲完上面的例子，优点已经十分明显了，那就是遵循了开闭原则，扩展性良好。

2. 缺点

• 随着你的策略增加，你的类也会越来越多。
• 所有的策略类都要暴露出去，所以如果你在实际开发中使用了策略模式，一定要记得写好文档让你的伙伴们知道已有哪些策略。就像 Shiro 默认提供了三种验证策略，就必须在文档中写清楚，否则我们根本不知道如何使用。

当然，权衡利弊，跟优点比起来，这些缺点都不算事儿。

第02课：装饰器模式

第03课：观察者模式

第04课：适配器模式

第05课：单例模式与工厂模式

第06课：模板方法模式

第07课：外观模式

第08课：代理模式

第09课：责任链模式

第10课：设计模式综合应用

阅读全文: http://gitbook.cn/gitchat/column/5b1e3647294fb04d7c22b783

相关资源：软件测试管理中软件项目需求分析总结_需求分析小结-其它代码类…