为什么你总是觉得设计模式很难？.

点击↑上方↑蓝色“编了个程”关注我~

荒腔走板

上周没更新，抱歉。周末去「重庆」浪了一圈，都被催更了。。。

也按照惯例说一下为什么会写这篇文章。

第一个是大家对设计模式比较感兴趣，也是每个程序员（尤其是使用面向对象语言的程序员）都应该去学习掌握的思维和工具。

第二个是平时工作中确实会用到，用了设计模式，不但能让你的程序更加健壮、可维护性更好，最主要的是，看起来逼格更高了！

第三个是设计模式确实不好学，我自己刚学设计模式的时候，老是感觉有点绕，很多，记不住。或者是「看似当时理解了，转眼就忘了，真到该用的时候，又一脸懵逼，不知道该用哪种设计模式」。不开玩笑，我相信你应该也有过这种感觉。

关于设计模式的书不少，上博客也有很多。那我会想，如果我要写一篇关于设计模式的文章，它给读者带来的价值在哪里呢只是机械地介绍一遍所有的设计模式，那其实没有多大意义。授人以鱼不如授人以渔，今天这篇文章我想探讨更多的，是「如何去认知和学习设计模式」，以及如何才能够真正让它为你所用，成为你编程的神兵利器，披荆斩棘。

关于设计模式的几个问题

首先想和大家探讨几个关于设计模式的问题，这是我在打算写这篇文章时脑海中浮现出来的一些问题，自己也尝试给出一些解答，欢迎大家交流探讨。

1 设计模式解决的是什么问题h3>

软件是一门工程，要实现功能很简单，但是在实现功能的基础上，还能把它做得更加「容易扩展，容易应对变化」，那就是软件的艺术。

你会发现，大部分时间，你并不是在从头写代码，而是在“改代码”。设计得好的代码会让你改起来非常的舒服，只需要改动很小的地方，甚至不需要任何改动，就能实现新的功能。而设计得不好的代码会让你改起来像是在排地雷，一改红一大片，这就是程序太过耦合的原因。

纵观所有的软件方法论，你会发现绝大多数都是在解决耦合的问题，都想尽力把程序做得高内聚，低耦合。

「设计模式解决的是使用面向对象带来的软件复杂性，尤其是面对变化的复杂性」。我们希望在最开始写代码阶段，就考虑到后来有可能发生的变化，然后把自己的程序设计得更加好一点，以后改动的代价尽量更小一点。

2 什么是设计模式的六大原则h3>

你去看所有关于设计模式的书和系列文章，基本上都会先介绍设计模式的六大原则。

上面提到设计模式解决的其实是使用面向对象带来的软件复杂性，那具体如何解决呢就是靠的这几条前人总结的原则。

「理解六大原则比理解具体的设计模式更加重要」，因为具体的设计模式是“术”，而六大原则是“道”。你会发现，各种各样的设计模式，都是遵循了这些六大原则中的一条或者多条。

?

其中，开闭原则有些特殊。它是最“虚”的，其它原则都可以看成是开闭原则的实现。

?

哪怕你写的程序没有用到任何已知的设计模式，也应该尽量去遵循这六大原则，这样你写出来的程序也不会太差，基本上都具有“高内聚，低耦合”的特点。

当然了，原则这个东西有时候是可以违背的，只是你要衡量违背它的代价和带来的收益，是否值得。

3 为什么通常说23种设计模式h3>

因为“设计模式”这个词是由四人帮（GoF）写的一本叫《Design Patterns》的书中提出来的，这本书里面总结了23种设计模式，也是「最常用的设计模式」。

所以设计模式其实并不止23种，只是因为这23种是比较常用的设计模式，它们分别适用于不同的场景，也覆盖了绝大多数软件设计的场景。这23种设计模式只是前人的“经验总结”或者“套路”，有时候经验还是蛮重要的，使用这些经验能够少走很多弯路。

有时候多种设计模式可以互相配合起来使用，或者在现有的23种设计模式之上有一些变化，甚至是总结出一些新的“套路”，用来解决现有23种设计模式不能解决的问题，都是正常的。设计模式并不是死的，一成不变的，它应该是灵活的。

4 怎样才能掌握设计模式h3>

设计模式这么多，而且那么灵活，那如何才能很好地驯服设计模式这匹野马呢p>

首先要理解六大设计原则，吃透他们，理解为什么有这几个原则，如果不遵循这几种原则会怎样了六大设计原则，才能更好地理解具体的设计模式。

在学习一个设计模式的时候，要理解「它解决了什么问题」不使用这种设计模式，会有什么坏处在下次面对类似的问题时，就能够想起有这么一种设计模式，可以解决这个问题。

然后可以自己写一写代码，感受一下这个设计模式是怎么用的，最好是举个例子，这样比较生动形象。再看看开源代码，看看大神们是怎么用这个设计模式的。

如何学习设计模式h2>

设计模式是一种“套路”，那学习设计模式也是可以有套路的。我们随便选择一个设计模式，来应用这种套路。比如“模板方法模式”。

解决了什么问题h3>

假如一个父类有多个子类，而有一些逻辑是「所有子类都共用」的。比如固定的流程，或者固定的分支逻辑。

如果不使用会怎样h3>

如果不使用模板方法模式，每个子类都自己实现一遍，那会产生很多「重复代码」，这样一旦要修改这些共用的逻辑，就需要修改每个子类。

遵循了什么原则h3>

里氏替换原则。模板方法中共有的逻辑定义在父类中，且不是abstract的，子类不应该去覆盖这个方法（可以在父类用final关键字修饰）。需要子类去实现的方法定义为abstract的，子类必须实现。

依赖倒置原则，面向接口或抽象类编程。客户端只需要依赖父类就行了，不需要依赖子类。

示例代码h3>

我们举一个适合使用模板方法的例子，比如注册。注册的流程是比较固定的，但注册的方式可以有很多种，比如邮箱注册或者手机注册。

首先我们来定义一个注册到发送验证码的流程：

输入用户名
验证用户名格式是否正确（邮箱或者手机）
如果格式不正确，抛出异常；如果格式正确，就注册成功，并发送验证码。

先定义抽象的父类：

然后分别定义子类的实现：

客户端大概长这样：

使用这个模式的开源代码

Spring的AbstractApplicationContext类的refresh方法，就是典型的模板方法模式的应用。了解过Spring源码的朋友应该看过这段代码。

我们把上面的“套路”总结成一个思维导图，大家可以依样画葫芦，对其它设计模式也试试用这个套路，看是否能够快速理解一个设计模式。

我是Yasin，一个有颜有料又有趣的程序员

个人站：https://yasinshaw.com

这里很多技术干货，关注肯定不后悔

听说，转发和在看的人都升职加薪了