《设计模式之美》- 总结

《设计模式之美》- 总结

第一章 概述

1.1 为什么学习代码设计

1. 编写高质量的代码
2. 应对复杂代码的开发
3. 程序员的基本功
4. 职业发展的必备技能

1.2 如何评价代码的质量

1.2.1 可维护性

可维护性代码的特性：
	代码简洁、可读性好、可扩展性好
	代码分层结构清晰、模块化程度高、高内聚低耦合、遵守基于接口而非实现编程的设计原则等
	还有跟项目的代码量、业务的复杂度、技术的复杂度、文档的全面性和团队成员的开发水平等因素有关

1.2.2 可读性

可读性的评判标准
	代码是否符合代码规范，比如命名是否达意、注释是否详尽、函数长度是否合适、模块划分是否清晰、代码是否高内聚、低耦合

1.2.3 可扩展性

评判标准
	指的是在不修改或少量修改原有代码的情况下，能够通过扩展方式添加新功能代码。
	是指在编写代码时预留了一些功能扩展点，可以把新功能直接插入扩展点，而不会因为添加新的功能代码而改动大量的原始代码。

1.2.4 灵活性

评判标准
	代码易扩展、易复用、或者易用，一般认为这段代码写的很灵活。

1.2.5 简洁性

简洁、清晰是写代码的首要原则，思从深而行从简，编程高手往往能用简单的方法解决复杂的问题。	
需要遵循KISS原则

1.2.6 可复用性

含义：尽量减少重复代码的编写，复用已有的代码
	继承、多态的目的之一是提高代码的复用性；
	单一职责原则与代码的复用性相关；
	解耦、高内聚和模块化等能提高代码的可复用性;
	是很多设计原则、设计思想和设计模式等所要实现的最终效果；

1.2.7 可测试性

代码的可测试性低，难以编写单元测试；

1.3 如何编写高质量代码

1.3.1 面向对象设计范式

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

1.3.2 设计原则

设计原则是心法、设计模式是招式；
设计原则比设计模式普适、重要；
只有掌握了设计原则，才能清楚地了解为什么使用某种设计模式，并且恰到好处地应用设计模式，甚至可以创造新的设计模式；
九种原则：
	1、单一职责原则（SRP）；
	2、开闭原则（OCP）；
	3、里氏替换原则（LSP）；
	4、接口隔离原则（ISP）；
	5、依赖反转原则（DIP）；
	6、KISS原则
	7、YAGNI原则
	8、DRY原则
	9、LoD原则

1.3.3 设计模式

大部分设计模式解决的是代码的解耦、可扩展性的问题；
重点需要掌握可以解决什么问题、典型的应用场景，并且不过度使用；
分三类：创建型、结构型、行为型；
学习设计原则和设计规范，需要融入很多的个人理解和思考；

1.3.4 代码规范

主要解决代码的可读性问题；
命名规范、注释规范等；

1.3.5 重构技巧

代码重构的工具：面向对象的编程范式、设计原则、设计模式、代码规范；
1、重构的目的、对象、时机、方法；
2、保证重构不出错的手段：单元测试、以及代码的可测试性；
3、大重构（大规模、高层次）、小重构（小规模、低层次）；

面向对象编程、设计原则、设计模式、代码规范和重构技巧之间的关系

1、面向对象因其丰富的特性（封装、抽象、继承、多态），可以实现很多复杂的设计思路，所以，它是很多设计原则、设计模式编程实现的基础；
2、设计原则是指导代码设计的一些经验总结，是代码设计的心法，指明了代码设计的大方向。相比设计模式，它更普适；
3、设计模式是针对软件开发中经常遇到的一些设计问题二总结的一套解决方案或设计思路。应用设计模式的主要目的是解耦，提高代码的可扩展性。从抽象角度上来讲，设计原则比设计模式更抽象。设计模式更加具体，更加容易落地执行。
4、代码规范解决的是代码的可读性问题，更加具体、更加偏重代码细节和更加容易落地执行。持续小重构的理论依据就是代码规范。
5、重构是保持代码质量不下降的有效手段，依靠的是面向对象编程范式、设计原则、设计模式、代码规范。

总结：
1、面向对象编程范式、设计原则、设计模式、代码规范、重构是保持或提高代码质量的方法论、指导思想，本质上都是服务于编写高质量代码。
2、如何才能熟练掌握以上方法：掌握理论知识、刻意的训练，最重要的是具备代码质量意识。
3、代码设计的方法：多思考未来有哪些扩展需求、哪部分代码是会变的、哪部分代码是不变的；

1.4 如何避免过度设计

1.4.1 初衷：提高代码质量

思考点：
为什么要这样设计、为什么要用这种设计模式、这样做是否能真正提高代码质量、能够提高代码哪些方面的质量；
如果回答不了上面的问题，基本上就是过度设计。

1.4.2 原则：先有问题，后有方案

分析代码现有问题的方法：
1、分析代码存在的痛点：比如可读性不高、可扩展性不高等；
2、有针对性地利用设计模式、设计原则对代码进行改善，不可随意套用；

1.4.3 代码设计的应用场景是复杂代码

应用设计模式的目的是解耦，解耦的目的是应对代码的复杂性问题。代码不复杂就没必要引入设计模式。
数据结构和算法应对的是大规模数据的问题。

1.4.持续重构可有效避免过度设计

设计模式可以提高代码的可扩展性，但是会降低代码的可读性；
持续重构，当有真正的痛点时，再考虑使用设计模式来解决，而不是一开始就为不一定实现的未来需求而应用设计模式；
在模棱两可时先不使用设计模式，当代码持续演进到足够复杂，如果不适用它就需要改动很多代码，这时才可以使用它；
能不用就不用，遵循KISS原则；

1.4.5 不要脱离具体的场景谈代码设计

脱离业务谈架构是不切实际的；
要重视分析问题能力和解决问题能力的锻炼；
能够分析代码的优秀之处和不足之处，并说明原因，以及要知道如何改善代码；