《设计模式之美》（1）设计模式导读

一、为什么学习设计模式

记录学习王铮的课程笔记：《设计模式之美》，感兴趣的可以购买下面链接课程。

https://time.geekbang.org/column/intro/250

基础知识是非常重要的，基础扎实，才能走得更远。然而设计模式和计算机基础学科（如：操作系统，计算机组成原理，编译原理等）相比是不太一样的，学习设计模式能直接提高你的开发能力。如果数据结构和算法是教你如何写出高效的代码，那设计模式则是指导你如何写出高质量的代码。
那么其实说为什么要学习设计模式，可以大致分为以下几点：

1. 应对大厂的面试
   大厂会比较重视候选人的基本功，经常会拿算法、设计模式之类的问题考察候选人的基本功是否扎实，有没有培养的价值。
2. 被人吐槽代码写的烂
   代码能力是一个程序员基础素养的衡量标准，代码写得好，在公司也会是他们学习的榜样，也能够在团队中脱颖而出。反之，代码写得差，会导致功能维护困难，经常被人吐槽。
3. 提高复杂通用的功能设计能力
   写代码完成功能可能并不复杂，复杂的是怎样写出易拓展，易使用，易维护的代码。
4. 学习优秀开源项目，开源框架的代码
   优秀的开源项目、框架都有一个非常明显的特点，为了保证代码的拓展性、灵活性、可维护性等，代码中会使用到很多设计模式，设计原则或者设计思想。如果对这些基础知识不了解，其实看了源码，可能还是没有学习到里面的精髓。
5. 为职业发展做准备
   一个只是把框架，开发工具用的很熟练，但是代码却是写得不咋滴的工程师，是成为不了大牛的。如果到了一定的阶段，需要指导初级员工，新人的工作的时候，如果自己对“什么是好的代码？”这个问题都没有自己的思考，甚至不了解，怎么保证上线系统的质量问题。

二、如何评价代码质量？

实际上，我们评价代码质量是多个维度的，代码质量的高低，是一个综合了各种因素得出来的结论。我们不能通过单一的维度去评价一段代码写的好坏。比如：一段代码的可拓展性很好，但是可读性很差，这种情况我们也不能说这段代码质量高。

我们不能客观的评价一段代码的质量，每个人的评价标准都不太一样，评价代码质量本身就是一个很难量化，非常主观的事情，因此工程师的经验越足，给出的评价就越准确。

那我们开发中最重用的，也最重要的有几个标准：可维护性、可读性、可拓展性、简洁性、可复用性、可测试性。其中，可维护性、可读性、可扩展性是提到最多的、最重要的三个评价标准。

1. 可维护性
   对于一个项目来说，维护代码的时间远远大于编写代码的时间。所谓的“维护”就是修改bug、修改老代码的逻辑、添加新的功能代码之类的工作。那我们所说的代码可维护性主要指的是：在不大改原有代码设计、不引入新的bug的情况下，能够快速地修改或者添加代码。
2. 可读性
   代码的可读性是评价代码质量最重要的指标之一。代码的可读性在非常大程度会影响代码的可维护性，如果代码都读不太懂，贸然修改了代码，就很可能因为考虑不周全的问题，引入新的bug。
   评价代码可读性，我们可以看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等。
   简单点来说，在code review的时候，如果同事可以很轻松地读懂你写的代码，说明你的代码可读性很好；如果同事在读你代码时，有很多疑问，那就说明代码的可读性有待提高。
3. 可拓展性
   可拓展性也是评价代码质量非常重要的标准。它说明我们的代码应对未来需求变化的能力。
   简单地来说，就是代码预留了功能拓展点，你可以新功能代码，直接写在拓展点上，而不需要因为添加一个功能而改动大量的原始代码。其实就是表达了一条设计原则“对修改关闭，对拓展开放”。
4. 简洁性
   有一条著名的设计原则叫KISS原则：“Keep it Simple ，Stupid”。这个原则表达的意思是：尽量保持代码简单。代码简单，逻辑清晰，也就意味着代码的可读性，以及可维护性。简而言之：用最简单的代码解决最复杂的问题。
5. 可复用性
   尽量减少重复代码的编写，复用已有的代码。在面向对象编程中，有两个重要的概念：继承和多态，目的就是为了提高代码的可复用性。可复用性也是一个非常重要的代码评价标准，是很多设计原则，思想，模式等所要表达的最终效果。
   另外，代码的可复用性也跟DRY（Don’t Repeat Yourself）这条设计原则的关系紧密相关。
6. 可测试性
   代码的可测试性是一个相对较少被提及，但又非常重要的代码质量评价标准。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。

三、重要名词说明

1. 面向对象
   大部分项目都是基于面向对象编程风格开发的，因为其拥有丰富的特性（封装，抽象，继承，多态），可以帮助我们实现很多复杂的设计思路，是很多设计原则，设计模式编码实现的基础。

2. 设计原则
   设计原则是知道我们代码设计得一些经验总结。我们需要掌握的是它设计得初衷，能够解决哪些问题，有哪些应用场景。只有这样，我们才能在开发项目过程中灵活恰当地应用这些原则。如下是几个常用的设计原则（SOLID意思：稳定的，把五个设计原则的首字母拼接起来就是SOLID）：

• SOLID原则-SRP单一职责原则（Single Responsibility Principle）
• SOLID原则-OCP开闭原则（Open Closed Principle）
• SOLID原则-LSP里氏替换原则（Liskov Substitution Principle）
• SOLID原则-ISP接口隔离原则（Interface Segregation Principle）
• SOLID原则-DIP依赖倒置原则（Dependence Inversion Principle）
• DRY原则（Don’t Repeat Yourself）（不要写重复代码）
• KISS原则（Keep it Simple ，Stupid）（尽量保持代码简单）
• YAGNI原则（You Ain’t Gonna Need It）（不要过度设计）
• LOD法则（Law of Demeter）（迪米特法则）

迪米特法的含义：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。它强调以下两点：

• 从依赖者的角度来说，只依赖应该依赖的对象。
• 从被依赖者的角度说，只暴露应该暴露的方法。

3. 设计模式
   设计模式是针对开发中经常遇到的一些设计问题，总结出来的一套解决方案或者设计思路。大部分的设计模式要解决的问题都是代码的可拓展性。我们需要做到的是了解每一种设计模式能够解决哪些问题，能够恰到好处的使用。
   经典的设计模式有23种。它们可以分为三大类：创建型、结构型、行为型。具体分类如下：

• 创建型
  常用的有：单例模式、工厂模式（工厂方法和抽象工厂）、建造者模式
  不常用的有：原型模式
• 结构型
  常用的有：代理模式、桥接模式、装饰者模式、适配器模式
  不常用的有：门面模式、组合模式、享元模式
• 行为型
  常用的有：观察者模式、模板模式、策略模式、责任链模式、迭代器模式、状态模式
  不常用的有：访问者模式、备忘录模式、命令模式、解释器模式、中介模式

4. 编程规范
   编程规范主要解决的是代码的可读性问题。编程规范相对于设计原则、设计模式、更加具体、更加偏重代码细节。比如：如何给变量、类、函数命名；如何写代码注释、函数不易过长、参数不能过多等等。

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

6. 五者联系
   面向对象编程因为其具有丰富的特性（封装、抽象、继承、多态），可以实现很多复杂的设计思路，因此面向对象是很多设计原则、设计模式等编码实现的基础。
   设计原则是指导我们代码设计的一些经验总结，对于某些场景下，是否应该应用某种设计模式，具有指导意义。而设计原则是指导我们代码设计的一些经验总结，因此设计原则对于某些场景下，是否应该应用某种设计模式，具有指导意义。
   编程规范主要解决的是代码的可读性问题。编码规范相对于设计原则、设计模式，更加具体、更加偏重代码细节、更加能落地。持续的小重构依赖的理论基础主要就是编程规范。
   重构作为保持代码质量不下降的有效手段，利用的就是面向对象、设计原则、设计模式、编码规范这些理论。