设计模式之美学习（一）：设计模式对编程工做者是很重要的，它的做用不言而喻。

继数据结构与算法之美后，王争老师的专栏又开始更新了，此次是《设计模式之美》，但愿学习以后会对本身有所提高。在此记录下本身的学习笔记，但愿对本身或者看到的读者都有所裨益。

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

1. 应对面试中的设计模式相关问题

学习设计模式和算法同样，最功利、最直接的目的，可能就是应对面试了。

无论你是前端工程师、后端工程师，仍是全栈工程师，在求职面试中，设计模式问题是被问得频率比较高的一类问题。特别是一些像 BAT、TMD 这样的大公司，比较重视候选人的基本功，常常会拿算法、设计模式之类的问题来考察候选人。

2. 告别写被人吐槽的烂代码

咱们常常说，Talk is cheap，show me the code。实际上，代码能力是一个程序员最基础的能力，是基本功，是展现一个程序员基础素养的最直接的衡量标准。你写的代码，实际上就是你名片。

3. 提升复杂代码的设计和开发能力

大部分工程师比较熟悉的都是编程语言、工具、框架这些东西，由于天天的工做就是在框架里根据业务需求，填充代码。实际上，这样的工做并不须要你具有很强的代码设计能力，只要单纯地能理解业务，翻译成代码就能够了。

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

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

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

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

有些人看源码的时候，常常会遇到看不懂、看不下去的问题。不知道你有没有遇到过这种状况？实际上，这个问题的缘由很简单，那就是你积累的基本功还不够，你的能力还不足以看懂这些代码。

5. 为你的职场发展作铺垫

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

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

总结

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

投资要趁早，这样咱们才能尽早享受复利。一样，有些能力，要早点锻炼；有些东西，要早点知道；有些书，要早点读。这样在你后面的生活、工做、学习中，才能一直都发挥做用。不要等到好多年后，看到了，才恍然大悟，后悔没有早点去学、去看。

设计模式做为一门与编码、开发有着直接关系的基础知识，是你如今就要开始学习的。早点去学习，之后的项目就均可以拿来锻炼，每写一行代码都是对内功的利用和加深，是能够受益一整个职业生涯的事情。

从哪些维度评判代码质量的好坏？如何具有写出高质量代码的能力？

对于程序员来讲，辨别代码写得“好”仍是“烂”，是一个很是重要的能力。这也是咱们写出好代码的前提。毕竟，若是咱们连什么是好代码、什么是烂代码，都分辨不清，又谈何写出好代码呢？

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

下面是描述代码质量的全部经常使用词汇：

灵活性（flexibility）、可扩展性（extensibility）、可维护性（maintainability）、可读性（readability）、可理解性（understandability）、易修改性（changeability）、可复用（reusability）、可测试性（testability）、模块化（modularity）、高内聚低耦合（high cohesion loose coupling）、高效（high effciency）、高性能（high performance）、安全性（security）、兼容性（compatibility）、易用性（usability）、整洁（clean）、清晰（clarity）、简单（simple）、直接（straightforward）、少便是多（less code is more）、文档详尽（well-documented）、分层清晰（well-layered）、正确性（correctness、bug free）、健壮性（robustness）、鲁棒性（robustness）、可用性（reliability）、可伸缩性（scalability）、稳定性（stability）、优雅（elegant）、好（good）、坏（bad）……

实际上，咱们很难经过其中的某个或者某几个词汇来全面地评价代码质量。由于这些词汇都是从不一样维度来讲的。这就比如，对于一我的的评价，咱们须要综合各个方面来给出，好比性格、相貌、能力、财富等等。代码质量高低也是一个综合各类因素获得的结论。咱们并不能经过单一的维度去评价一段代码写的好坏。好比，即便一段代码的可扩展性很好，但可读性不好，那咱们也不能说这段代码质量高。

除此以外，不一样的评价维度也并非彻底独立的，有些是具备包含关系、重叠关系或者能够互相影响的。好比，代码的可读性好、可扩展性好，就意味着代码的可维护性好。不过，咱们真的能够客观地量化一段代码质量的高低吗？答案是否认的。对一段代码的质量评价，经常有很强的主观性。

正是由于代码质量评价的主观性，使得这种主观评价的准确度，跟工程师自身经验有极大的关系。越是有经验的工程师，给出的评价也就越准确。因此，这也致使若是没有人指导的话，本身一我的闷头写代码，即使写再多的代码，代码能力也可能一直没有太大提升。

最经常使用的评价标准有哪几个？

其中几个最经常使用的、最重要的评价标准，来详细讲解，其中就包括：可维护性、可读性、可扩展性、灵活性、简洁性（简单、复杂）、可复用性、可测试性。

1. 可维护性（maintainability）

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

维护、易维护、不易维护这三个概念不难理解。不过，对于实际的软件开发来讲，更重要的是搞清楚，如何来判断代码可维护性的好坏。从正面去分析一个代码是否易维护稍微有点难度。不过，咱们能够从侧面上给出一个比较主观但又比较准确的感觉。若是 bug 容易修复，修改、添加功能可以轻松完成，那咱们就能够主观地认为代码对咱们来讲易维护。相反，若是修改一个 bug，修改、添加一个功能，须要花费很长的时间，那咱们就能够主观地认为代码对咱们来讲不易维护。

2. 可读性（readability）

软件设计大师 Martin Fowler 曾经说过：Any fool can write code that a computer can understand. Good programmers write code that humans can understand.翻译成中文就是：“任何傻瓜都会编写计算机能理解的代码。好的程序员可以编写人可以理解的代码。”

代码的可读性应该是评价代码质量最重要的指标之一。咱们在编写代码的时候，时刻要考虑到代码是否易读、易理解。除此以外，代码的可读性在很是大程度上会影响代码的可维护性。毕竟，无论是修改 bug，仍是修改添加功能代码，咱们首先要作的事情就是读懂代码。代码读不大懂，就颇有可能由于考虑不周全，而引入新的 bug。

既然可读性如此重要，那咱们又该如何评价一段代码的可读性呢？

实际上，code review 是一个很好的测验代码可读性的手段。若是你的同事能够轻松地读懂你写的代码，那说明你的代码可读性很好；若是同事在读你的代码时，有不少疑问，那就说明你的代码可读性有待提升了。

3. 可扩展性（extensibilty）

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

代码的可扩展性表示，咱们在不修改或少许修改原有代码的状况下，经过扩展的方式添加新的功能代码。说直白点就是，代码预留了一些功能扩展点，你能够把新功能代码，直接插到扩展点上，而不须要由于要添加一个功能而大动干戈，改动大量的原始代码。

4. 灵活性（flexibility）

灵活性是一个挺抽象的评价标准，要给灵活性下个定义也是挺难的。不过，咱们能够想一下，什么状况下咱们才会说代码写得好灵活呢？我这里罗列了几个场景，但愿能引起你本身对什么是灵活性的思考。

• 当咱们添加一个新的功能代码的时候，原有的代码已经预留好了扩展点，咱们不须要修改原有的代码，只要在扩展点上添加新的代码便可。这个时候，咱们除了能够说代码易扩展，还能够说代码写得好灵活。
• 当咱们要实现一个功能的时候，发现原有代码中，已经抽象出了不少底层能够复用的模块、类等代码，咱们能够拿来直接使用。这个时候，咱们除了能够说代码易复用以外，还能够说代码写得好灵活。
• 当咱们使用某组接口的时候，若是这组接口能够应对各类使用场景，知足各类不一样的需求，咱们除了能够说接口易用以外，还能够说这个接口设计得好灵活或者代码写得好灵活。

从刚刚举的场景来看，若是一段代码易扩展、易复用或者易用，咱们均可以称这段代码写得比较灵活。因此，灵活这个词的含义很是宽泛，不少场景下均可以使用。

5. 简洁性（simplity）

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

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

6. 可复用性（reusability）

代码的可复用性能够简单地理解为，尽可能减小重复代码的编写，复用已有的代码。实际上，代码可复用性跟 DRY（Don’t Repeat Yourself）这条设计原则的关系挺紧密的.

7. 可测试性（testability）

相对于前面六个评价标准，代码的可测试性是一个相对较少被说起，但又很是重要的代码质量评价标准。代码可测试性的好坏，能从侧面上很是准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。

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

问如何写出高质量的代码，也就等同于在问，如何写出易维护、易读、易扩展、灵活、简洁、可复用、可测试的代码。

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

总结

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

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

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

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

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

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

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

面向对象

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

须要掌握的7大知识点：

• 面向对象的四大特性：封装、抽象、继承、多态
• 面向对象编程与面向过程编程的区别和联系
• 面向对象分析、面向对象设计、面向对象编程
• 接口和抽象类的区别以及各自的应用场景
• 基于接口而非实现编程的设计思想
• 多用组合少用继承的设计思想
• 面向过程的贫血模型和面向对象的充血模型

设计原则

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

须要掌握的经常使用设计原则：

• SOLID 原则 -SRP 单一职责原则
• SOLID 原则 -OCP 开闭原则
• SOLID 原则 -LSP 里式替换原则
• SOLID 原则 -ISP 接口隔离原则
• SOLID 原则 -DIP 依赖倒置原则
• DRY 原则、KISS 原则、YAGNI 原则、LOD 法则

设计模式

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

经典的设计模式能够分为三大类：建立型、结构型、行为型。

1. 建立型

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

2. 结构型

经常使用的有：代理模式、桥接模式、装饰者模式、适配器模式。
不经常使用的有：门面模式、组合模式、享元模式。

3. 行为型

经常使用的有：观察者模式、模板模式、策略模式、职责链模式、迭代器模式、状态模式。
不经常使用的有：访问者模式、备忘录模式、命令模式、解释器模式、中介模式。

编程规范

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

代码重构

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

而重构的工具就是咱们前面罗列的那些面向对象设计思想、设计原则、设计模式、编码规范。

须要掌握的知识点有：

• 重构的目的（why）、对象（what）、时机（when）、方法（how）；
• 保证重构不出错的技术手段：单元测试和代码的可测试性；
• 两种不一样规模的重构：大重构（大规模高层次）和小重构（小规模低层次）。

五者之间的联系

• 面向对象编程由于其具备丰富的特性（封装、抽象、继承、多态），能够实现不少复杂的设计思路，是不少设计原则、设计模式等编码实现的基础。
• 设计原则是指导咱们代码设计的一些经验总结，对于某些场景下，是否应该应用某种设计模式，具备指导意义。好比，“开闭原则”是不少设计模式（策略、模板等）的指导原则。
• 设计模式是针对软件开发中常常遇到的一些设计问题，总结出来的一套解决方案或者设计思路。应用设计模式的主要目的是提升代码的可扩展性。从抽象程度上来说，设计原则比设计模式更抽象。设计模式更加具体、更加可执行。
• 编程规范主要解决的是代码的可读性问题。编码规范相对于设计原则、设计模式，更加具体、更加偏重代码细节、更加能落地。持续的小重构依赖的理论基础主要就是编程规范。
• 重构做为保持代码质量不降低的有效手段，利用的就是面向对象、设计原则、设计模式、编码规范这些理论。

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

总结

欢迎小伙伴们和我一块儿学习。

本文由博客一文多发平台 OpenWrite 发布！
更多内容请点击个人博客 沐晨