设计模式-理论基础

如有侵权，请联系～
如有错误，也欢迎批评指正～

一、代码质量指标

我们想要写出一个好的代码，首先要知道什么是好的代码，代码质量的评价指标有很多：

灵活性（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容易修复，修改、添加功能能够轻松完成，那我们就可以主观地认为代码对我们来说易维护。

2.可读性（readability）

实际上，code review是一个很好的测验代码可读性的手段。如果你的同事可以轻松地读懂你写的代码，那说明你的代码可读性很好；如果同事在读你的代码时，有很多疑问，那就说明你的代码可读性有待提高了。

3.可扩展性（extensibility）

可扩展性也是一个评价代码质量非常重要的标准。它表示我们的代码应对未来需求变化的能力。跟可读性一样，代码是否易扩展也很大程度上决定代码是否易维护。

代码的可扩展性表示，我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。说直白点就是，代码预留了一些功能扩展点，你可以把新功能代码，直接插到扩展点上，而不需要因为要添加一个功能而大动干戈，改动大量的原始代码。

4.灵活性（flexibility）

我们可以想一下，什么情况下我们才会说代码写得好灵活呢？我这里罗列了几个场景，希望能引发你自己对什么是灵活性的思考。

当我们添加一个新的功能代码的时候，原有的代码已经预留好了扩展点，我们不需要修改原有的代码，只要在扩展点上添加新的代码即可。这个时候，我们除了可以说代码易扩展，还可以说代码写得好灵活。

当我们要实现一个功能的时候，发现原有代码中，已经抽象出了很多底层可以复用的模块、类等代码，我们可以拿来直接使用。这个时候，我们除了可以说代码易复用之外，还可以说代码写得好灵活。

当我们使用某组接口的时候，如果这组接口可以应对各种使用场景，满足各种不同的需求，我们除了可以说接口易用之外，还可以说这个接口设计得好灵活或者代码写得好灵活。

从刚刚举的场景来看，如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活。所以，灵活这个词的含义非常宽泛，很多场景下都可以使用。

5.简洁性（simplicity）

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

6.可复用性（reusability）

代码的可复用性可以简单地理解为，尽量减少重复代码的编写，复用已有的代码。

7.可测试性（testability）

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

二、设计原则

1. 单一责任原则 (Single Responsibility Principle, SRP)

定义：一个类应该只有一个责任，也就是说，它应该只有一个引起其变化的原因。
意义：通过确保每个类只有一个职责，我们能使代码更简洁、更易于理解和测试。

2. 开放/闭合原则 (Open/Closed Principle, OCP)

定义：软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭。
意义：这意味着可以通过添加新的代码来扩展系统的功能，而不需要修改现有的代码，从而减少了潜在的错误风险。

3. 里氏替换原则 (Liskov Substitution Principle, LSP)

定义：子类对象应该能够替换父类对象，且不影响程序的正确性。
意义：确保子类能够完全代替父类的使用场景，从而提高代码的复用性和灵活性。

4. 接口隔离原则 (Interface Segregation Principle, ISP)

定义：一个类不应该强迫客户端依赖于它不使用的接口。
意义：通过将庞大的接口拆分为多个小接口，可以降低类之间的耦合度，使得更高的模块独立性和灵活性。

5. 依赖倒置原则 (Dependency Inversion Principle, DIP)

定义：高层模块不应该依赖低层模块，两个模块都应该依赖于抽象；抽象不应该依赖细节，细节应该依赖于抽象。
意义：通过依赖于抽象而不是具体实现，促进了代码的松耦合和灵活性。

6. 合成/聚合复用原则 (Composite Reuse Principle)

定义：尽量使用对象组合而不是继承来实现代码的复用。
意义：通过组合，我们可以在运行时选择行为，且不需要更改类层次结构，更加灵活。

7. 最少知识原则 (Law of Demeter, LoD)

定义：一个对象应该对其他对象有尽可能少的了解，只与直接的朋友交互。
意义：降低对象之间的耦合，从而更易于维护和修改代码。

三、设计模式

可以分为三大类：创建型、结构型、行为型。

1. 创建型

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

不常用的有：原型模式。

2.结构型

常用的有：代理模式、桥接模式、装饰者模式、适配器模式。

不常用的有：门面模式、组合模式、享元模式。

3.行为型

常用的有：观察者模式、模板模式、策略模式、职责链模式、迭代器模式、状态模式。

不常用的有：访问者模式、备忘录模式、命令模式、解释器模式、中介模式。