程序设计原则

1 设计模式的目的

可复用：避免出现重复代码
可读性：代码规范性，易于阅读
可扩展性： 增加新功能的时候，非常方便。或者称为可维护性
可靠性：新增功能对原有功能不能有影响。

2 SOLID原则

单一职责原则（SRP）
开放封闭原则（OCP)
里氏替换原则（LSP）
接口隔离原则（ISP）
依赖倒置原则（DIP）

3 单一职责原则

3.1 基本介绍

一个类值应该负责一个职责。

3.2 注意事项

如果一个类的方法比较少，可以在方法级别保持单一职责原则。

4 开闭原则

基本介绍

（1） 一个软件实体（如类、模块或者函数）应该对扩展开放（对提供方提出的要求），对修改关闭（对使用方提出的要求）。用抽象构建框架，用实现扩展细节。
（2） 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有代码来实现变化。

5 里氏替换原则

5.1 OO中存在的问题

如果子类通过继承的方式对父类中实现的方法进行任意的修改，会对整个继承体系造成破坏。使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性。 父类修改时，必须考虑到所有的子类，如果父类修改不合理，涉及到的子类都有可能产生故障。

5.2 基本介绍

（1）如果对每个类型为T1的对象O1，都有类型为T2的对象O2，使得程序P中以T1类型定义的所有对象O1都替换成为O2时，程序P的行为没有发生变化，那么T2类型是T1的子类型。换言之，所有引用基类的地方都必须能透明地使用其子类的对象。
（2） 子类中尽量不重写父类的方法。
（3） 适当的情况下，通过使用聚合、组合和依赖来解决问题。

6 接口隔离原则（Interface Segregation Principle）

6.1 引例

6.2 基本介绍

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。

7 依赖倒置原则（Dependence Inversion Principle）

7.1 基本介绍

高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象。
依赖倒置的中心思想就是面向接口编程。

依赖倒置基于如下设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构要比以细节为基础搭建的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类。

使用接口或者抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

7.2 依赖关系传递的三种方式

接口传递
构造方法传递
Setter传递

7.3 注意事项

（1）低层模块尽量有抽象类或者接口，或者两者都有，程序稳定性更好。
（2）变量的声明类型尽量都是抽象类或者接口，这样变量引用和实例之间就存在一个缓冲层，利于程序的扩展和优化。
（3）继承时遵循里氏替换原则。

8 迪米特法则

8.1 基本介绍

一个对象应该对其他对象保持最少的了解。

类与类关系越密切，耦合度越大。

迪米特法则又称最少知道原则（Demeter Principle），即一个类对自己依赖的类知道的越少越好。 也就是说，对于依赖的类不管多么复杂，都应该尽可能将逻辑封装在类内部。对外除了提供public方法，不对外泄露任何信息。

迪米特复杂有更简单的定义：只与直接的朋友进行通信。

每个对象都会与其他对象有耦合关系，只要两个对象有耦合关系，就称为两个对象之间有朋友关系。耦合的方式有很多，依赖，关联，组合、聚合等。将成员变量、方法参数和方法返回值等关系称为直接朋友关系。 出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类内部。

8.2 注意事项

迪米特法则的核心就是：降低类之间的耦合。
注意：追求的是尽可能降低类之间的耦合，而不是追求类之间完全没有耦合关系。

9 合成复用原则

9.1 引例

如果类B想要使用类A的一些方法，可以使用继承、依赖、聚合和组合等这几种方法实现。

9.2 基本介绍

尽量使用合成或者聚合，而不是直接使用继承。

9.3 此原则的核心思路

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混合在一起。

针对接口进行编程，而不是针对实现进行编程。

追求对象之间的松耦合。

参考材料

[1] https://www.bilibili.com/video/BV1gJ411X7uN?p=21&vd_source=f4dcb991bbc4da0932ef216329aefb60
[2] https://zhuanlan.zhihu.com/p/82324809