前言:
学习设计模式的目的本质是为了写出高质量代码。
一、如何评判代码质量的好坏
怎样的代码才算是高质量的代码呢,作者给出了以下维度的标准。
1、可维护性
代码易维护是指在不破坏原有代码设计、不引入新的 bug 的情况下,能够快速且轻易地修改或者添加代码。或者反过来说,修改原有代码时不容易引入新bug,以及出现bug之后容易修复和功能容易扩展那就是好维护。
上面说的是一种结果,我们说能做到这种结果的代码就是可维护性高的结果。
下面我们来说说怎样做才能做到可维护性高。如果代码分层清晰、模块化好、高内聚低耦合、基于接口而非实现编程的设计原则,那就可能产出易维护的代码。
2、可读性
这点很简单,如果你的同事可以轻松地读懂你写的代码,那说明你的代码可读性很好;如果同事在读你的代码时,有很多疑问,那就说明你的代码可读性有待提高。
3、可扩展性
代码的可扩展性表示,我们在不修改或少量修改原有代码的情况下,通过新增代码的方式(例如编写子类,在子类中重写/实现父类方法)达到扩展新功能的目的。也就是所谓的“对修改关闭,对扩展开放”原则。
要做到这一点,我们需要在原有的代码上预留扩展点,更具体一点就是例如在父类声明一个空方法,让子类根据自己的场景来实现该方法。
4、简洁性
具体点就是让一个函数或者一个类的功能尽可能简单且职责专一,满足KISS原则(Keep It Simple,Stupid)。
5、可复用性
具体点就是将一个特定功能封装成一个函数或者类达到在项目不同地方重复使用,而非每用一次就重复写一次的目的。解耦、高内聚、模块化等都能提高代码的可复用性,可复用性也是很多设计原则、思想、模式等所要达到的最终效果。
上面这几个标准中,可扩展性最重要,没有之一。尤其是对于快速迭代的商业化需求而言,扩展性几乎就决定了每一次新迭代的速度、难度和效率。
二、为了写出高质量代码我们要了解什么
为了写出高质量代码,我们要了解面向对象、设计原则、设计模式、编程规范和重构这5个方面,下面这5点也是本系列文章的大纲。
1、面向对象
目前主流的编程风格有三种:面向过程、面向对象和函数式编程。面向对象是这其中最主流的。
对于面向对象编程,我们需要学会以下几点:
a. 面向对象的四大特性:封装、抽象、继承、多态;
b. 面向对象编程与面向过程编程的区别和联系
c. 面向对象分析、面向对象设计、面向对象编程
d. 接口和抽象类的区别以及各自的应用场景
e. 基于接口而非实现编程的设计思想
f. 多用组合少用继承
g. 面向过程的贫血模型和面向对象的充血模型
2、设计原则
设计原则是指导我们代码设计的一些经验总结,听起来都比较抽象,我们需要掌握它的设计初衷,能解决哪些编程问题,有哪些应用场景,这样才不会“感觉学了,但有感觉没学”。
有以下设计原则:
SOLID 原则 -SRP 单一职责原则
SOLID 原则 -OCP 开闭原则
SOLID 原则 -LSP 里式替换原则
SOLID 原则 -ISP 接口隔离原则
SOLID 原则 -DIP 依赖倒置原则
DRY 原则、KISS 原则、YAGNI 原则、LOD 法则
3、设计模式
设计模式是设计原则的具象化范例,或者说是符合了一个或多个设计原则的优秀实现。通过使用这些设计模式,我们相当于套用了这些优秀模板就能实现上面的设计原则,而不用自己去想如何设计代码来满足上面的设计原则,典型的站在巨人的肩膀。
经典的设计模式有 23 种(当然这23种里面有些已经过时,甚至变成了反面教材),它们又可以分为三大类。
a. 创建型
如单例模式、工厂模式、建造者模式。
b. 结构型
如代理模式、桥接模式、装饰者模式、适配器模式、门面模式、组合模式、享元模式。
c. 行为型
如观察者模式、模板模式、策略模式、职责链模式、迭代器模式、状态模式。
4、编程规范
编程规范主要解决的是代码的可读性问题。具体内容包括:如何给变量、类、函数命名,如何写代码注释,函数不宜过长、参数不能过多。
5、重构
重构就是通过上面的4点将代码从一个丑女重新整形为一个美女。那假如说我的代码本来就是一个“美女”了,用不着重构,那我只能说兄弟天真了,因为项目中某个模块的代码不是只有你一个人写,而是随着迭代经过多个人不停的添加新功能和修改,代码会变得复杂,你无法保证它一直保持优美和高质量。
这里只有一个原则:在开发初期一定不要过度设计,应用复杂的设计模式,而是尽可能少的用这些设计模式,怎么简单怎么来(除非你能预判这个业务模块之后会增加些什么功能,那你可以根据未来要实现的功能做好铺垫,而使用相应的设计模式)。
在后期,当代码出现问题的时候,我们再针对问题应用原则和模式进行重构。
这个原则可以帮助我们避免过度设计 和 节省开发成本。
对于重构,需要掌握以下几点:重构的目的、对象、时机、方法;
怎么重构才能不引入新bug:单元测试和代码的可测试性;
两种不同规模的重构:大重构和小重构;
最后根据个人经验送给大家的一句话:当我们学完上述所有原则和模式之后,真的到了开发中,实际上还是靠感觉来设计代码(只不过学了这些知识之后可以让我们的“感觉”更正确和敏锐),而不用照本宣科的“这样做可以实现这个原则,这样做就用到了这个设计模式”,不要为了用而用,而是为了解决问题而用。