六大设计原则主要是指：

  • 单一职责原则（Single Responsibility Principle）；
  • 开闭原则（Open Closed Principle）；
  • 里氏替换原则（Liskov Substitution Principle）；
  • 迪米特法则（Law of Demeter），又叫“最少知道法则”；
  • 接口隔离原则（Interface Segregation Principle）；
  • 依赖倒置原则（Dependence Inversion Principle）。

单一职责原则

定义：一个类应该只有一个发生变化的原因

那这个原则有什么用呢，它让类的职责更单一。这样的话，每个类只需要负责自己的那部分，类的复杂度就会降低。如果职责划分得很清楚，那么代码维护起来也更加容易。试想如果所有的功能都放在了一个类中，那么这个类就会变得非常臃肿，而且一旦出现bug，要在所有代码中去寻找；更改某一个地方，可能要改变整个代码的结构，想想都非常可怕。当然一般时候，没有人会去这么写的。

当然，这个原则不仅仅适用于类，对于接口和方法也适用，即一个接口/方法，只负责一件事，这样的话，接口就会变得简单，方法中的代码也会更少，易读，便于维护。

事实上，由于一些其他的因素影响，类的单一职责在项目中是很难保证的。通常，接口和方法的单一职责更容易实现。

单一原则的好处：

代码的粒度降低了，类的复杂度降低了。
可读性提高了，每个类的职责都很明确，可读性自然更好。
可维护性提高了，可读性提高了，一旦出现 bug ，自然更容易找到他问题所在。
改动代码所消耗的资源降低了，更改的风险也降低了。

开闭原则

定义：一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭

那么开闭原则具体是什么呢？可以说，开闭原则贯穿于以上五个设计模式原则。开闭原则中的对扩展开放，就是说，如果在项目中添加一个功能的时候，可以直接对代码进行扩展；如果要修改某一部分的功能时，我们应该做的是，尽量少做修改（完全不修改是不可能的），但是修改的时候，要保留原来的功能，只是在上面扩展出新的功能，就像版本更新一样，更新后，依然支持旧版本。

里氏替换原则

定义：所有引用基类的地方必须能透明地使用其子类的对象

里氏替换原则的意思是，所有基类在的地方，都可以换成子类，程序还可以正常运行。这个原则是与面向对象语言的 继承 特性密切相关的。

这是为什么呢？由于面向对象语言的继承特性，子类拥有父类的所有方法，因此，将基类替换成具体的子类，子类也可以调用父类中的方法（其实是它自己的方法，继承于父类），但是如果要保证完全可以调用，光名称相同不行，还需要满足下面两个条件：

  • 子类中的方法的前置条件必须与超类中被覆写的方法的前置条件相同或更宽松。
  • 子类中的方法的后置条件必须与超类中被覆写的方法的后置条件相同或更严格。

这样的话，调用就没有问题了。否则，我在父类中传入一个 List 类型的参数，子类中重写的方法参数却变为 ArrayList ，那客户端使用的时候传入一个 LinkedList 类型的参数，使用父类的时候程序正常运行，但根据 LSP 原则，替换成子类后程序就会出现问题。同理，后置条件也是如此。

迪米特法则

定义：迪米特法则（LoD）也叫最少知道法则：一个对象应该对其他对象有最少的了解。

这个原则也没什么需要多讲的，调用者只需要知道被调用者公开的方法就好了，至于它内部是怎么实现的或是有其他别的方法，调用者并不关心，调用者只关心它需要用的。反而，如果被调用者暴露太多不需要暴露的属性或方法，那么就可能导致调用者滥用其中的方法，或是引起一些其他不必要的麻烦。

接口隔离原则

定义：
1、客户端不应该依赖它不需要的接口。
2、类间的依赖关系应该建立在最小的接口上

这是什么意思呢，这是让我们把接口进行细分。举个例子，如果一个类实现一个接口，但这个接口中有它不需要的方法，那么就需要把这个接口拆分，把它需要的方法提取出来，组成一个新的接口让这个类去实现，这就是接口隔离原则。简而言之，就是说，接口中的所有方法对其实现的子类都是有用的。否则，就将接口继续细分。

看起来，该原则与单一职责原则很相像。确实很像，二者都是强调要将接口进行细分，只不过分的方式不同。单一职责原则是按照 职责 进行划分接口的；而接口隔离原则则是按照实现类对方法的使用来划分的。可以说，接口隔离原则更细一些。

要想完美地实现该原则，基本上就需要每个实现类都有一个专用的接口。但实际开发中，这样显然是不可能的，而且，这样很容易违背单一职责原则（可能出现同一个职责分成了好几个接口的情况），因此我们能做的就是尽量细分。

该原则主要强调两点：

接口尽量小。

就像前面说的那样，接口中只有实现类中有用的方法。

接口要高内聚

就是说，在接口内部实现的方法，不管怎么改，都不会影响到接口外的其他接口或是实现类，只能影响它自己。

依赖倒置原则

定义：
1、上层模块不应该依赖底层模块，它们都应该依赖于抽象。
2、抽象不应该依赖于细节，细节应该依赖于抽象。

解释：

高层模块不应该依赖底层模块，两者都应该依赖其抽象。
抽象不应该依赖细节。
细节应该依赖抽象。

在Java语言中的表现就是：

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
接口或抽象类不依赖于实现类。
实现类依赖于接口或抽象类。
简而言之，我们要尽可能使用接口或抽象类。也就是“面向接口编程” 或者说 “面向抽象编程” ，也就是说程序中要尽可能使用抽象类或是接口。

参考链接
维基百科：https://zh.wikipedia.org/wiki/SOLID_(%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1)

CSDN：https://blog.csdn.net/rocketeerli/article/details/81585705

知乎：https://zhuanlan.zhihu.com/p/110130347