设计模式入门

1. 建立完善的知识体系

在整个专栏中，我试图给你建立完善的知识体系，所以，从内容上来讲，涵盖了编写高质量代码的方方面面，比如面向对象、设计原则、设计思想、编码规范、重构技巧、设计模式。虽然在有限的 100 篇文章、50 万字内，我可能没法儿把每一个知识点都讲解得无比详细、全面，但我整理的这份知识框架，相当于给你指出了一个深入研究的方向，你可以按图索骥，积累起来会更快。先建立整体的知识框架，再慢慢深入、各个攻破，这也是学习任何一门新技术、新知识最有效的方法。

所以，这里给你布置一个小任务，闭上眼睛，想一想整个专栏都会讲哪些内容？已经讲过的设计原则和思想，都讲了哪些内容？你能想起来多少？

2. 建立代码质量意识

实际上，建立正确的技术认知和技术观，比单纯学技术、学知识点更重要。

我举个例子，专栏中讲到单元测试的时候，并没有讲跟某个测试框架相关的技术点。因为我觉得这些很容易通过看文档学习，而我也不可能写得比文档更全面、更权威。实际上，通过那节课，我想要让你了解的是单元测试的好处，让你真正意识到单元测试的重要性，从心底认可这件事。还有，我在讲到重构的时候，也一直在强调要建立持续重构意识。整个专栏也都是在传递给你代码质量的重要性，让你意识到好代码和差代码的差别在哪里。

在学完专栏的时候，如果某些原则、思想、模式你记不大清了，那也没关系，只要你能在写代码的时候，能不由自主地去思考代码质量，有意识地去打磨代码，对代码质量有所追求了，那就说明你入门了，也就达到了我们专栏学习的目的。至于具体的知识点，随着时间的推移有所忘记，实际上并不碍事，多看几遍，多实践实践就好了。

这里，我也问你一个问题，你可以想一想，你写代码或者读别人代码的时候，是否开始思考代码质量问题呢？如果还没有，那再给你布置一个任务，在今后的一个月内，写代码前、中、后，都思考一下代码的扩展性、可读性、可维护性、可测试性等代码质量问题，看看自己编写的代码是否符合这些质量要求，有没有需要继续优化重构的地方。

3. 主动学习而非被动学习

“师傅领进门，修行靠个人”，这句话说得特别好。同样听一个老师讲课，一个班级里面总有人会考 90 分，甚至满分，也会总会有人考不及格。差距在哪里呢？道理很简单，那就是你有没有用心学习。

类比到我们的专栏学习中，如果你只是走马观花地看一遍、跟听小说一样听一遍，收获肯定是甚微的，也就会出现常说的“过不几天就忘了”的情况。因为这是一种被动学习方法，左耳朵进右耳朵出，脑子里怎么会留住东西呢？相反，如果你能学会主动学习、主动思考，遇到不会的、理解不了的知识点，自己主动去思考一下、查查资料，或者跟同事讨论一下，试着把专栏里的内容自己总结一下，认真思考每一个课后题，这样的学习效果要比被动学习强好几倍。

关于这一点，我也给你留个作业：找一篇你觉得还没有透彻理解的文章，花上一天的时间，把里面的代码自己实现一遍，把文章的重点内容自己思考、整理，输出成文章。你可以看看，这样是否要比单纯看一遍收获更多呢？

4. 多读几遍更有收获

《设计模式之美》专栏的内容都不难理解，每篇文章仅有四五千字，十几分钟的音频，但是，多读几遍你就会发现，每读一遍都会有不同的收获。

如果你只是看一遍、听一遍，怎么能达到像我一样对知识点的理解程度呢？我自己在写专栏的时候，可是查阅了大量的文章和资料。有的时候，一篇文章我要写好几天，这期间有长时间、高强度的阅读、思考和揣摩。你如果都不愿意花跟我一样多的时间，怎么能期望跟我有一样的水平呢？

一个人的认知和理解能力是受限于他的经历和经验的。如果你刚毕业不久，开发经验不多，看专栏的时候，难免会抓不住重点或者理解得不够透彻。那该怎么办呢？我的建议是，千万不要把学习专栏看成一蹴而就的事情，看完一遍就丢在一边了，而是要反反复复进行学习。看一遍理论之后，你可以在项目中尝试着实践一下，然后回过头来再看一遍，直到没有新的知识点可以汲取为止。这个过程可能需要持续很长时间，可能是 1 年、2 年甚至是 3 年、5 年，但只有这样，你才能积累出真正的能力、建立真正的竞争壁垒，而不只是学一些快餐知识、填补眼前的焦虑。

在《数据结构与算法之美》专栏中，我也说过，你要做一个长一点的学习计划。实际上，学习《设计模式之美》专栏也是如此，毕竟这两门课都是比较基础的，而且跟我们平时的开发比较相关，多花点时间在基础的知识上，收益要远大于学习很多花哨的新技术、新框架。

关于这一点，我再给你布置一个作业：找专栏中一篇文章，反复读上 10 遍（当然是带着思考去读哈）。你看看是不是比只读一遍要理解得更透彻？是不是之前不能理解的地方自然就理解了呢？是不是每次读的时候都有新的收获？

5. 学会把代码写到极致

我经常说，写 100 段烂代码都不如写 1 段好代码，对代码能力的提高大。实际上，这个道理也可以应用到任何学习工作中，堆量只需要时间，但并不是每个人都能把事情做到极致，而能把一件事情做到极致的人，往往也能把其他很多事情做到极致。这也是为什么，很多人在某一行业做得很好，跨行去做另一个看似不相干的事情也同样能做得非常好。牛人往往都是能把一件事情做到极致的人。如果所有的事情都只能做到一般好，那你注定也只能做一个平凡的人。

关于这一点，我也布置一个作业给你：找一段你觉得写得很烂的代码，花上一个礼拜的时间，反复思考如何优化，把它优化到足够好。

总结

说了这么多，说实话，我知道这些道理很多人都知道。但是，能真正落实执行，并且执行到位的人不多。就光我说的这几个作业，估计能 100% 完成的也没有几个人。

你说人和人之间的差距在哪里？就在这里。

不要期望我的专栏有什么杀手锏可以教给你，不要期望看了我的专栏之后不费力气就能成为代码高手。还是那句话，师傅领进门，修行靠个人。我能做的就是尽量地将知识讲得通俗、透彻，把我的经验尽可能地传授给你，而这些只占 1%，剩下 99% 都要靠你自己去努力。

如果说成为代码高手是万里长征，那我只能给你指明方向，告诉你如何去走。剩下的万里长征没人能替你去走，需要你一步一步、踏踏实实，自己去走完。

为什么每个程序员都要尽早地学习并掌握设计模式相关知识？

提高复杂代码的设计和开发能力

大部分工程师比较熟悉的都是编程语言、工具、框架这些东西，因为每天的工作就是在框架里根据业务需求，填充代码。实际上，我刚工作的时候，也是做这类事情。相对来说，这样的工作并不需要你具备很强的代码设计能力，只要单纯地能理解业务，翻译成代码就可以了。

但是，有一天，我的 leader 让我开发一个跟业务无关的比较通用的功能模块，面对这样稍微复杂的代码设计和开发，我就发现我有点力不从心，不知从何下手了。因为我知道只是完成功能、代码能用，可能并不复杂，但是要想写出易扩展、易用、易维护的代码，并不容易。

如何分层、分模块？应该怎么划分类？每个类应该具有哪些属性、方法？怎么设计类之间的交互？该用继承还是组合？该使用接口还是抽象类？怎样做到解耦、高内聚低耦合？该用单例模式还是静态方法？用工厂模式创建对象还是直接 new 出来？如何避免引入设计模式提高扩展性的同时带来的降低可读性问题？……各种问题，一下子挤到了我面前。

而我当时并没有对设计模式相关的知识（包括设计模式、设计原则、面向对象设计思想等）有太多的了解和积累，所以一时间搞得我手足无措。好在因此我意识到了这方面知识的重要性，所以在之后很多年的开发中，我都一直刻意锻炼、积累这方面的能力。面对复杂代码、功能、系统的设计和开发，我也越来越得心应手，游刃有余。写出高质量代码已经成为了我的习惯，不经意间写出来的代码，都能作为同事学习、临摹的范例，这也成为了我职场中最引以为豪的亮点之一。

让读源码、学框架事半功倍

对于一个有追求的程序员来说，对技术的积累，既要有广度，也要有深度。很多技术人早早就意识到了这一点，所以在学习框架、中间件的时候，都会抽空去研究研究原理，读一读源码，希望能在深度上有所积累，而不只是略知皮毛，会用而已。

从我的经验和同事的反馈来看，有些人看源码的时候，经常会遇到看不懂、看不下去的问题。不知道你有没有遇到过这种情况？实际上，这个问题的原因很简单，那就是你积累的基本功还不够，你的能力还不足以看懂这些代码。为什么我会这么说呢？

优秀的开源项目、框架、中间件，代码量、类的个数都会比较多，类结构、类之间的关系极其复杂，常常调用来调用去。所以，为了保证代码的扩展性、灵活性、可维护性等，代码中会使用到很多设计模式、设计原则或者设计思想。如果你不懂这些设计模式、原则、思想，在看代码的时候，你可能就会琢磨不透作者的设计思路，对于一些很明显的设计思路，你可能要花费很多时间才能参悟。相反，如果你对设计模式、原则、思想非常了解，一眼就能参透作者的设计思路、设计初衷，很快就可以把脑容量释放出来，重点思考其他问题，代码读起来就会变得轻松了。

实际上，除了看不懂、看不下去的问题，还有一个隐藏的问题，你可能自己都发现不了，那就是你自己觉得看懂了，实际上，里面的精髓你并没有 get 到多少！因为优秀的开源项目、框架、中间件，就像一个集各种高精尖技术在一起的战斗机。如果你想剖析它的原理、学习它的技术，而你没有积累深厚的基本功，就算把这台战斗机摆在你面前，你也不能完全参透它的精髓，只是了解个皮毛，看个热闹而已。

因此，学好设计模式相关的知识，不仅能让你更轻松地读懂开源项目，还能更深入地参透里面的技术精髓，做到事半功倍。

为你的职场发展做铺垫

普通的、低级别的开发工程师，只需要把框架、开发工具、编程语言用熟练，再做几个项目练练手，基本上就能应付平时的开发工作了。但是，如果你不想一辈子做一个低级的码农，想成长为技术专家、大牛、技术 leader，希望在职场有更高的成就、更好的发展，那就要重视基本功的训练、基础知识的积累。

你去看大牛写的代码，或者优秀的开源项目，代码写得都非常的优美，质量都很高。如果你只是框架用得很溜，架构聊得头头是道，但写出来的代码很烂，让人一眼就能看出很多不合理的、可以改进的地方，那你永远都成不了别人心目中的“技术大牛”。

为什么要学习设计模式相关的知识，总结一下的话，主要有这样五点：应对面试中的设计模式相关问题；告别写被人吐槽的烂代码；提高复杂代码的设计和开发能力；让读源码、学框架事半功倍；为你的职场发展做铺垫。

---

1.设计模式很主要，很主要，很主要。他是一个能够长久迭代开发的必要条件，也是一个提高开发效率的必要条件。当我第一次用设计模式的时候我激动的一晚上没睡好，反反复复去看我的代码，喜欢的不得了。我会对照我的代码思考需求变更我的代码应该改什么，那种解耦合，可扩展的架构真的喜欢！！！

如何评价代码质量的高低？

如果没有人指导的话，自己一个人闷头写代码，即便写再多的代码，代码能力也可能一直没有太大提高。

1. 可维护性（maintainability）

我们首先来看，什么是代码的“可维护性”？所谓的“维护代码”到底包含哪些具体工作？

落实到编码开发，所谓的“维护”无外乎就是修改 bug、修改老的代码、添加新的代码之类的工作。所谓“代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。所谓“代码不易维护”就是指，修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成。

我们知道，对于一个项目来说，维护代码的时间远远大于编写代码的时间。工程师大部分的时间可能都是花在修修 bug、改改老的功能逻辑、添加一些新的功能逻辑之类的工作上。所以，代码的可维护性就显得格外重要。

维护、易维护、不易维护这三个概念不难理解。不过，对于实际的软件开发来说，更重要的是搞清楚，如何来判断代码可维护性的好坏。

实际上，可维护性也是一个很难量化、偏向对代码整体的评价标准，它有点类似之前提到的“好”“坏”“优雅”之类的笼统评价。代码的可维护性是由很多因素协同作用的结果。代码的可读性好、简洁、可扩展性好，就会使得代码易维护；相反，就会使得代码不易维护。更细化地讲，如果代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则等等，那就可能意味着代码易维护。除此之外，代码的易维护性还跟项目代码量的多少、业务的复杂程度、利用到的技术的复杂程度、文档是否全面、团队成员的开发水平等诸多因素有关。

所以，从正面去分析一个代码是否易维护稍微有点难度。不过，我们可以从侧面上给出一个比较主观但又比较准确的感受。如果 bug 容易修复，修改、添加功能能够轻松完成，那我们就可以主观地认为代码对我们来说易维护。相反，如果修改一个 bug，修改、添加一个功能，需要花费很长的时间，那我们就可以主观地认为代码对我们来说不易维护。

你可能会说，这样的评价方式也太主观了吧？没错，是否易维护本来就是针对维护的人来说的。不同水平的人对于同一份代码的维护能力并不是相同的。对于同样一个系统，熟悉它的资深工程师会觉得代码的可维护性还不错，而一些新人因为不熟悉代码，修改 bug、修改添加代码要花费很长的时间，就有可能会觉得代码的可维护性不那么好。这实际上也印证了我们之前的观点：代码质量的评价有很强的主观性。

2. 可读性（readability）

软件设计大师 Martin Fowler 曾经说“任何傻瓜都会编写计算机能理解的代码。好的程序员能够编写人能够理解的代码。”

我个人认为，代码的可读性应该是评价代码质量最重要的指标之一。我们在编写代码的时候，时刻要考虑到代码是否易读、易理解。除此之外，代码的可读性在非常大程度上会影响代码的可维护性。毕竟，不管是修改 bug，还是修改添加功能代码，我们首先要做的事情就是读懂代码。代码读不大懂，就很有可能因为考虑不周全，而引入新的 bug。

如何评价一段代码的可读性？

看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等。你应该也能感觉到，从正面上，我们很难给出一个覆盖所有评价指标的列表。这也是我们无法量化可读性的原因。

实际上，code review 是一个很好的测验代码可读性的手段。如果你的同事可以轻松地读懂你写的代码，那说明你的代码可读性很好；如果同事在读你的代码时，有很多疑问，那就说明你的代码可读性有待提高了。

3. 可扩展性（extensibility）

可扩展性也是一个评价代码质量非常重要的标准。它表示我们的代码应对未来需求变化的能力。跟可读性一样，代码是否易扩展也很大程度上决定代码是否易维护。什么是代码的可扩展性呢？

代码的可扩展性表示，我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。说直白点就是，代码预留了一些功能扩展点，你可以把新功能代码，直接插到扩展点上，而不需要因为要添加一个功能而大动干戈，改动大量的原始代码。

关于代码的扩展性，在后面讲到“对修改关闭，对扩展开放”这条设计原则的时候，我会来详细讲解，今天我们只需要知道，代码的可扩展性是评价代码质量非常重要的标准就可以了。

4. 灵活性（flexibility）

灵活性也是描述代码质量的一个常用词汇。比如我们经常会听到这样的描述：“代码写得很灵活”。那这里的“灵活”该如何理解呢？

尽管有很多人用这个词汇来描述代码的质量。但实际上，灵活性是一个挺抽象的评价标准，要给灵活性下个定义也是挺难的。不过，我们可以想一下，什么情况下我们才会说代码写得好灵活呢？我这里罗列了几个场景，希望能引发你自己对什么是灵活性的思考。

当我们添加一个新的功能代码的时候，原有的代码已经预留好了扩展点，我们不需要修改原有的代码，只要在扩展点上添加新的代码即可。这个时候，我们除了可以说代码易扩展，还可以说代码写得好灵活。

当我们要实现一个功能的时候，发现原有代码中，已经抽象出了很多底层可以复用的模块、类等代码，我们可以拿来直接使用。这个时候，我们除了可以说代码易复用之外，还可以说代码写得好灵活。

当我们使用某组接口的时候，如果这组接口可以应对各种使用场景，满足各种不同的需求，我们除了可以说接口易用之外，还可以说这个接口设计得好灵活或者代码写得好灵活。

从刚刚举的场景来看，如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活。所以，灵活这个词的含义非常宽泛，很多场景下都可以使用。

5. 简洁性（simplicity）

有一条非常著名的设计原则，你一定听过，那就是 KISS 原则：“Keep It Simple，Stupid”。这个原则说的意思就是，尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护。我们在编写代码的时候，往往也会把简单、清晰放到首位。

不过，很多编程经验不足的程序员会觉得，简单的代码没有技术含量，喜欢在项目中引入一些复杂的设计模式，觉得这样才能体现自己的技术水平。实际上，思从深而行从简，真正的高手能云淡风轻地用最简单的方法解决最复杂的问题。这也是一个编程老手跟编程新手的本质区别之一。

除此之外，虽然我们都能认识到，代码要尽量写得简洁，符合 KISS 原则，但怎么样的代码才算足够简洁？不是每个人都能很准确地判断出来这一点。所以，在后面的章节中，当我们讲到 KISS 原则的时候，我会通过具体的代码实例，详细给你解释，“为什么 KISS 原则看似非常简单、好理解，但实际上用好并不容易”。今天，我们就暂且不展开详细讲解了。

6. 可复用性（reusability）

代码的可复用性可以简单地理解为，尽量减少重复代码的编写，复用已有的代码。

比如，当讲到面向对象特性的时候，我们会讲到继承、多态存在的目的之一，就是为了提高代码的可复用性；当讲到设计原则的时候，我们会讲到单一职责原则也跟代码的可复用性相关；当讲到重构技巧的时候，我们会讲到解耦、高内聚、模块化等都能提高代码的可复用性。可见，可复用性也是一个非常重要的代码评价标准，是很多设计原则、思想、模式等所要达到的最终效果。

实际上，代码可复用性跟 DRY（Don’t Repeat Yourself）这条设计原则的关系挺紧密的，所以，在后面的章节中，当我们讲到 DRY 设计原则的时候，我还会讲更多代码复用相关的知识，比如，“有哪些编程方法可以提高代码的复用性”等。

7. 可测试性（testability）

相对于前面六个评价标准，代码的可测试性是一个相对较少被提及，但又非常重要的代码质量评价标准。代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。关于代码的可测试性，我们在重构那一部分，会花两节课的时间来详细讲解。现在，你暂时只需要知道，代码的可测试性非常重要就可以了。

如何才能写出高质量的代码？

我相信每个工程师都想写出高质量的代码，不想一直写没有成长、被人吐槽的烂代码。那如何才能写出高质量的代码呢？针对什么是高质量的代码，我们刚刚讲到了七个最常用、最重要的评价指标。所以，问如何写出高质量的代码，也就等同于在问，如何写出易维护、易读、易扩展、灵活、简洁、可复用、可测试的代码。

要写出满足这些评价标准的高质量代码，我们需要掌握一些更加细化、更加能落地的编程方法论，包括面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。而所有这些编程方法论的最终目的都是为了编写出高质量的代码。

比如，面向对象中的继承、多态能让我们写出可复用的代码；编码规范能让我们写出可读性好的代码；设计原则中的单一职责、DRY、基于接口而非实现、里式替换原则等，可以让我们写出可复用、灵活、可读性好、易扩展、易维护的代码；设计模式可以让我们写出易扩展的代码；持续重构可以时刻保持代码的可维护性等等。具体这些编程方法论是如何提高代码的可维护性、可读性、可扩展性等等的呢？我们在后面的课程中慢慢来学习。

重点回顾

今天的内容到此就讲完了。我们来一起回顾一下，你需要重点掌握的几个知识点。

1. 如何评价代码质量的高低？

代码质量的评价有很强的主观性，描述代码质量的词汇也有很多，比如可读性、可维护性、灵活、优雅、简洁等，这些词汇是从不同的维度去评价代码质量的。它们之间有互相作用，并不是独立的，比如，代码的可读性好、可扩展性好就意味着代码的可维护性好。代码质量高低是一个综合各种因素得到的结论。我们并不能通过单一的维度去评价一段代码的好坏。

2. 最常用的评价标准有哪几个？

最常用到几个评判代码质量的标准是：可维护性、可读性、可扩展性、灵活性、简洁性、可复用性、可测试性。其中，可维护性、可读性、可扩展性又是提到最多的、最重要的三个评价标准。

3. 如何才能写出高质量的代码？

要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等等，这也是我们后面课程学习的重点。

课堂讨论

除了我今天提到的这些，你觉得还有哪些其他的代码评价标准非常重要？聊一聊你心目中的好代码是什么样子的？

1 机器的运行效率 （往往还和可读性相冲突，但又非绝对冲突） ， 有时候算法在没优化好的时候，时间空间是可以一起省下来的。
2 代码可管理行数。 好的代码，层次分明，职能分明，让人感受到代码品味。

1. 当你读我代码的时候，我已经不在了，但你依然能够清楚清晰的明白我要传递的信息
2. 当程序出错时，一方面我汇报的错误信息能够帮你找出你的错误在哪; 另一方面，你能准确告诉我，我到底错哪了，而不是说："xx接口报错了，你看下怎么回事"
3. 当你需要造个轮子的时候，我的代码能够作为现成的轮毂，你只需要再配上其他的组装一下

除了小争哥提到的七个评价标准，我认为还有一个评价标准：易debug。在日常工作中，经常要追查各种线上case，代码是否易于debug，会非常影响工程师的追查效率。比如是否有打印详细的日志，是否有debug干涉点可以在debug模式下打印详细的线上请求信息便于快速定位问题。当然，这一点也可以放在可维护性中。

面向对象、设计原则、设计模式、编程规范、重构，这五者有何关系？

面向对象

现在，主流的编程范式或者是编程风格有三种，它们分别是面向过程、面向对象和函数式编程。面向对象这种编程风格又是这其中最主流的。现在比较流行的编程语言大部分都是面向对象编程语言。大部分项目也都是基于面向对象编程风格开发的。面向对象编程因为其具有丰富的特性（封装、抽象、继承、多态），可以实现很多复杂的设计思路，是很多设计原则、设计模式编码实现的基础。

所以，在专栏的最开始，我们会详细地讲解面向对象编程的相关的知识，为学习后面的内容做铺垫。对于这部分内容，你需要掌握下面这 7 个大的知识点。

面向对象的四大特性：封装、抽象、继承、多态

面向对象编程与面向过程编程的区别和联系

面向对象分析、面向对象设计、面向对象编程

接口和抽象类的区别以及各自的应用场景

基于接口而非实现编程的设计思想

多用组合少用继承的设计思想

面向过程的贫血模型和面向对象的充血模型

设计原则

设计原则是指导我们代码设计的一些经验总结。设计原则这块儿的知识有一个非常大的特点，那就是这些原则听起来都比较抽象，定义描述都比较模糊，不同的人会有不同的解读。所以，如果单纯地去记忆定义，对于编程、设计能力的提高，意义并不大。对于每一种设计原则，我们需要掌握它的设计初衷，能解决哪些编程问题，有哪些应用场景。只有这样，我们才能在项目中灵活恰当地应用这些原则。

对于这一部分内容，你需要透彻理解并且掌握，如何应用下面这样几个常用的设计原则。

SOLID 原则 -SRP 单一职责原则

SOLID 原则 -OCP 开闭原则

SOLID 原则 -LSP 里式替换原则

SOLID 原则 -ISP 接口隔离原则

SOLID 原则 -DIP 依赖倒置原则

DRY 原则、KISS 原则、YAGNI 原则、LOD 法则

设计模式

设计模式是针对软件开发中经常遇到的一些设计问题，总结出来的一套解决方案或者设计思路。大部分设计模式要解决的都是代码的可扩展性问题。设计模式相对于设计原则来说，没有那么抽象，而且大部分都不难理解，代码实现也并不复杂。这一块的学习难点是了解它们都能解决哪些问题，掌握典型的应用场景，并且懂得不过度应用。

经典的设计模式有 23 种。随着编程语言的演进，一些设计模式（比如 Singleton）也随之过时，甚至成了反模式，一些则被内置在编程语言中（比如 Iterator），另外还有一些新的模式诞生（比如 Monostate）。

在专栏中，我们会重点讲解 23 种经典的设计模式。它们又可以分为三大类：创建型、结构型、行为型。对于这 23 种设计模式的学习，我们要有侧重点，因为有些模式是比较常用的，有些模式是很少被用到的。对于常用的设计模式，我们要花多点时间理解掌握。对于不常用的设计模式，我们只需要稍微了解即可。

我按照类型和是否常用，对专栏中讲到的这些设计模式，进行了简单的分类，具体如下所示。

1. 创建型

常用的有：单例模式、工厂模式（工厂方法和抽象工厂）、建造者模式。

不常用的有：原型模式。

2. 结构型

常用的有：代理模式、桥接模式、装饰者模式、适配器模式。

不常用的有：门面模式、组合模式、享元模式。

3. 行为型

常用的有：观察者模式、模板模式、策略模式、职责链模式、迭代器模式、状态模式。

不常用的有：访问者模式、备忘录模式、命令模式、解释器模式、中介模式。

编程规范

编程规范主要解决的是代码的可读性问题。编码规范相对于设计原则、设计模式，更加具体、更加偏重代码细节。即便你可能对设计原则不熟悉、对设计模式不了解，但你最起码要掌握基本的编码规范，比如，如何给变量、类、函数命名，如何写代码注释，函数不宜过长、参数不能过多等等。

对于编码规范，考虑到很多书籍已经讲得很好了（比如《重构》《代码大全》《代码整洁之道》等）。而且，每条编码规范都非常简单、非常明确，比较偏向于记忆，你只要照着来做可以。它不像设计原则，需要融入很多个人的理解和思考。所以，在这个专栏中，我并没有花太多的篇幅来讲解所有的编码规范，而是总结了我认为的最能改善代码质量的 20 条规范。如果你暂时没有时间去看那些经典的书籍，看我这些就够了。

除此之外，专栏并没有将编码规范单独作为一个模块来讲解，而是跟重构放到了一起。之所以这样做，那是因为我把重构分为大重构和小重构两种类型，而小重构利用的知识基本上就是编码规范。

除了编码规范，我们还会介绍一些代码的坏味道，让你知道什么样的代码是不符合规范的，应该如何优化。参照编码规范，你可以写出可读性好的代码；参照代码的坏味道，你可以找出代码存在的可读性问题。

代码重构

在软件开发中，只要软件在不停地迭代，就没有一劳永逸的设计。随着需求的变化，代码的不停堆砌，原有的设计必定会存在这样那样的问题。针对这些问题，我们就需要进行代码重构。重构是软件开发中非常重要的一个环节。持续重构是保持代码质量不下降的有效手段，能有效避免代码腐化到无可救药的地步。

而重构的工具就是我们前面罗列的那些面向对象设计思想、设计原则、设计模式、编码规范。实际上，设计思想、设计原则、设计模式一个最重要的应用场景就是在重构的时候。我们前面讲过，虽然使用设计模式可以提高代码的可扩展性，但过度不恰当地使用，也会增加代码的复杂度，影响代码的可读性。在开发初期，除非特别必须，我们一定不要过度设计，应用复杂的设计模式。而是当代码出现问题的时候，我们再针对问题，应用原则和模式进行重构。这样就能有效避免前期的过度设计。

对于重构这部分内容，你需要掌握以下几个知识点：

重构的目的（why）、对象（what）、时机（when）、方法（how）；

保证重构不出错的技术手段：单元测试和代码的可测试性；

两种不同规模的重构：大重构（大规模高层次）和小重构（小规模低层次）。

希望你学完这部分内容之后，不仅仅是掌握一些重构技巧、套路，更重要的是建立持续重构意识，把重构当作开发的一部分，融入到日常的开发中。

五者之间的联系

关于面向对象、设计原则、设计模式、编程规范和代码重构，这五者的关系我们前面稍微提到了一些，我这里再总结梳理一下。

面向对象编程因为其具有丰富的特性（封装、抽象、继承、多态），可以实现很多复杂的设计思路，是很多设计原则、设计模式等编码实现的基础。

设计原则是指导我们代码设计的一些经验总结，对于某些场景下，是否应该应用某种设计模式，具有指导意义。比如，“开闭原则”是很多设计模式（策略、模板等）的指导原则。

设计模式是针对软件开发中经常遇到的一些设计问题，总结出来的一套解决方案或者设计思路。应用设计模式的主要目的是提高代码的可扩展性。从抽象程度上来讲，设计原则比设计模式更抽象。设计模式更加具体、更加可执行。

编程规范主要解决的是代码的可读性问题。编码规范相对于设计原则、设计模式，更加具体、更加偏重代码细节、更加能落地。持续的小重构依赖的理论基础主要就是编程规范。

重构作为保持代码质量不下降的有效手段，利用的就是面向对象、设计原则、设计模式、编码规范这些理论。

实际上，面向对象、设计原则、设计模式、编程规范、代码重构，这五者都是保持或者提高代码质量的方法论，本质上都是服务于编写高质量代码这一件事的。当我们追本逐源，看清这个本质之后，很多事情怎么做就清楚了，很多选择怎么选也清楚了。比如，在某个场景下，该不该用这个设计模式，那就看能不能提高代码的可扩展性；要不要重构，那就看重代码是否存在可读、可维护问题等。

重点回顾

今天的内容到此就讲完了。我画了一张图，总结了专栏中所涉及的知识点。在学习后面的课程的时候，你可以经常翻出来看一下，建立全局意识，不至于迷失在零碎的知识点中。

课堂讨论

今天课堂讨论的话题有两个。

在今天讲到的内容中，你觉得哪一部分内容对提高代码质量最有效？为什么？除了我罗列的这些内容之外，你还知道哪些可以提高代码质量的方法？

我们知道，最经典的设计模式书籍是 GoF 的《设计模式》，它的中文全称是《设计模式：可复用面向对象软件的基础》，英文全称是“Design Patterns: Elements of Reusable Object-Oriented Software”。为什么它在标题中会特意提到“面向对象”呢？

 最近一直在思考一个问题，就是我们在开发过程中，写好代码，应该是一个程序员必备的基本功。这个好字就是这老师说的高质量的代码，以前一直觉得要追求最热最新的技术，不然就会被淘汰。其实忘记了一个最基本的事情，怎么写好代码，写高质量的代码，这个才是我们开发过程中的重点，写好代码应该是一个合格的程序员必备的技能，毕竟写代码才是我们真真正正吃饭的家伙。

总结：提高代码质量的方法论，包含面向对象（基础），设计原则（指导方针），设计模式（三大类，提高扩展性），编程规范（提高可读性），重构（保证代码质量）。