设计原则 --《设计模式之美》总结篇

本文是阅读《设计模式之美》的总结和心得，跳过了书中对面试和工作用处不大或不多的知识点，总结总共分为三章，分别是面对对象编程范式、设计原则和设计模式。

设计模式是代码设计时的一些经验总结。相比于设计模式，设计原则更抽象。

单一职责原则（SRP）

一个类或模块只负责完成一个职责。
例如，某个类既包含对订单的一些操作，又包含对用户的一些操作。而订单和用户是两个独立的业务领域模型，将两个不相干的功能放到同一个类中，就违反了单一职责原则。

开闭原则（OCP）

开闭原则告诉我们在设计功能模块的时候要留扩展点，在未来进行需求变更时，不需要改动代码的整体结构，新的代码能够灵活地插入到扩展点，完成需求变更，从而实现代码的最小化改动。
同时，新增代码要比修改原有代码引入新 bug 的概率更小，基本所有的行为型设计模式都提供了扩展点。

里氏替换原则（LSP）

子类对象能够替换到程序中父类对象出现的任何地方，并且保证程序原有的逻辑行为不变和正确性不被破坏。
里氏替换原则乍一看好像和多态特性没有什么区别，因为多态的定义就是在程序运行的过程中，我们可以用子类替换父类，并调用子类的方法。里氏替换原则规定子类除了可以替换父类之外，子类不能违反父类对输入、输出和异常的约定，比如父类中的方法注释中注明方法不会抛出异常，返回值不会为 null，而子类重写父类方法后会抛出 RuntimeException 异常并且返回值可能为 null。这就违反了里氏替换原则，子类替换父类后可能给程序引入错误。还有一种场景，子类完全改变了父类的代码逻辑，如父类中是按时间排序，子类中却按大小排序。这也是违反里氏替换原则的。

接口隔离原则（ISP）

客户端不应该被强迫依赖它不需要的接口。
接口隔离原则和单一职责原则关系密切，满足单一职责原则的类不一定满足接口隔离原则，因为单一职责原则关注类自身实现的业务职责是否单一，而接口隔离原则关注客户端，如果客户端依赖的接口可以访问到它不需要的方法，说明客户端被强迫依赖了它不需要的接口，此时我们需要继续对接口细分，让接口满足接口隔离原则。

依赖反转原则（DIP）

高层模块不要依赖底层模块，高层模块和底层模块应该通过抽象互相依赖。
提到依赖反转，我们会联想到控制反转（IOC）和依赖注入（DI）。控制反转讲的是原来由程序员手动控制的模板代码变成由框架控制，这里说的模板代码可以是程序流程的控制、对象的创建等。因此，控制反转并不是一种具体的实现技巧，而是一种比较笼统的设计想法，一般用来指导框架的设计。依赖注入是指不通过 new 的方式在类内部创建依赖的类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递给类使用。

KISS原则

KISS原则的英文描述是：Keep It Simple and Stupid。中文释义是保持代码简单和愚蠢。
我们知道，代码的可读性是衡量代码质量的两个重要标准。而 KISS 原则就是保持代码可读和可维护的重要手段。代码足够简单，也就意味着容易读懂，bug 比较难隐藏，即使出现 bug，修复也比较简单。
对于如何写出满足 KISS 原则的代码，有两个方面：

1. 不要重复造轮子，首先考虑使用已有类库。
2. 不要过度设计。尽量避免使用一些 “奇技淫巧”，比如位运算，复杂的条件语法等。

DRY 原则

DRY 原则（Don’t Repeat Yourself）翻译成中文是：不要编写重复的代码。
满足 DRY 原则其实间接让我们提高了代码的复用性，因为代码复用性高，重复的代码自然就少了。

迪米特原则（LoD）

迪米特原则又称为最少知识原则。它规定不应该存在直接依赖关系的类之间不要有依赖，有依赖关系的类之间尽量只依赖必要的接口。
迪米特原则表述的后半部分其实就是接口隔离原则。这条原则能够帮助我们实现代码的 “高内聚，低耦合”。
“高内聚” 用来指导类本身的设计，指的是相近的功能应该放在同一个类中，不相近的功能不要放在同一个类中。
“低耦合” 用来指导类之间依赖关系的设计。指的是在代码中，类之间的依赖关系要简单、清晰。即使两个类有依赖关系，一个类的代码的改动不会或很少导致依赖类的代码的改动。