《设计模式》-代码质量评价标准和设计原则

系列文章目录

《设计模式》-代码质量评价标准和设计原则
《设计模式》- 创建型（单例模式、工厂模式、建造者模式、原型模式）
《设计模式》- 结构型（代理模式、装饰者模式、适配器模式、桥接模式、门面模式、组合模式、亨元模式）

---

---

前言

学习设计模式时，整理的一些知识，分为几篇文章进行归纳和总结。

---

一、代码质量评价标准

1. 可维护性（maintainability）

“代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。

“代码不易维护”就是指，修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能
完成。

2. 可读性（readability）

任何傻瓜都会编写计算机能理解的代码。好的程序员能够编写人能够理解的代码。

3. 可扩展性（extensibility）

代码的可扩展性表示，我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。

4. 灵活性（flexibility）

如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活。

5. 简洁性（simplicity）

尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护。我们在编写代码的时候，往往也会把
简单、清晰放到首位。

6. 可复用性（reusability）

尽量减少重复代码的编写，复用已有的代码。

7. 可测试性（testability）

代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，
那基本上就能说明代码设计得有问题。

其中比较常用的三个标准是：可维护性、可读性、可扩展性。

二、设计原则

1. SRP 单一职责原则

一个类或者模块只负责完成一个职责（或者功能）

2. OCP 开闭原则

软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。

3. LSP 里式替换原则

子类对象（object of subtype/derived class）能够替换程序（program）中
父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）
不变及正确性不被破坏。

子类在设计的时候，要遵守父类的行为约定（或者叫协议）。父类定义了函数的行为约定，那子类可以改变函数的
内部实现逻辑，但不能改变函数原有的行为约定。这里的行为约定包括：函数声明要实现的功能；对输入、输出、
异常的约定；甚至包括注释中所罗列的任何特殊说明。

4. ISP 接口隔离原则

客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。

5. DIP 依赖倒置原则

高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过
抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），
具体实现细节（details）依赖抽象（abstractions）。

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

-   DRY

    不要写重复的代码。

-   KISS

    尽量保持简单

-   YAGNI

    不要去设计当前用不到的功能；不要去编写当前用不到的代码。核心思想就是：不要做过度设计。

-   LOD

    不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。