设计原则
参考链接：https://datawhalechina.github.io/sweetalk-design-pattern/#/content/design_principles/dependence_inversion_principle
主要介绍以下五个设计原则：
1、单一职责原则
顾名思义，一个类只有一个职责，只会因为一个原因修改它。
为了便于代码维护、修改和复用，需要遵循单一职责原则，将不同职责划分开到不同的类中去实现，每个类只负责一个职责。
比如说《大话设计模式【java溢彩加强版】》中的一个计算器例子，在该例子中，要求输入两个数字，进行加减乘除操作。
正常思维就是卡卡一顿写，先写输入，然后根据输入进行运算判断，最终进行运算操作，输出结果。整个流程发生在一个类中，具体如下：
易知上述的控制台输入和计算是合并在一块的，并不灵活，也不方便后期的维护和扩展。正确的做法应该是将计算和显示功能分开来。同时计算的逻辑也可以复用到别的地方。
2、开闭原则
开闭原则要求对扩展开放，对修改关闭，即在新增功能时最好是在现有的代码进行扩展，而不是修改现有的代码。
还是延续上述计算器例子，根据例子要求，对数字进行加减乘除操作，很容易联想到之后的改变，若要增加其他操作，就要在已有代码的基础上，不停的添加运算分支。且需要对开发人员提供所有运算的代码，这显然是没有必要的。
因此，正常的做法是将运算操作抽象出来得到Operation父类，然后构建不同运算的子类（Add/Sub/Mul/Div)去继承父类，每个子类重写运算方法来实现不同运算操作。这样以后出现新的功能要求，比如添加求幂运算，就只需要添加一个求幂运算的子类即可。
具体代码如下：
Operation运算类
加法和减法类
3、依赖倒置原则
程序不依赖细节，而依赖于抽象。
在实际应用中，通过接口或者抽象类制定规范，再用实现类去实现具体的细节，实现松耦合。
以计算器例子来说，我们将运算操作抽象出来得到Operation类，具体细节让Add/Sub等实现类去实现。
4、里氏替换原则
子类能够替换它们的父类，即父类能够复用，子类能在父类的基础上进行扩展。
具体使用：
- 父类一般使用抽象类或者接口。
- 抽象类定义公共对象和状态；接口定义公共行为。
- 子类通过继承父类和接口进行扩展。
5、迪米特原则
也叫最小知识原则，强调两个类之间的松耦合，不必发生直接联系，而是通过第三者来中转。同时减少类对外公开的方法和变量。
以买房子为例，以下内容来源博客：https://blog.csdn.net/weixin_44564365/article/details/87920573
人直接知道房子的信息（包括大小、装修、层数），如下图：
这显示不符合迪米特原则以及实际情况，于是通过添加一个中介类来减少耦合：
这还存在一个问题，如果中介跑了，或者房子不卖了，怎么办？于是再次进行改进添加中介公司接口和房源接口。
这样买房的时候就可以找中介公司，中介公司找中介，也可以找房子，更方便、灵活，也应用到了依赖倒置原则！
