单一职责原则
大多数人都从字面上认为，编写代码中每个模块都应该只做一件事，即确保一个函数只完成一个功能，但这只是一个面向底层实现细节的设计原则，
并不是全部，在历史上，曾经这样描述这一原则：任何一个软件模块都应该有且仅有一个被修改的原因。而这个被修改的原因就是用户或都所有者。
举个反面例子：比如说代码编写着将计算a的方法和计算b的方法混合成方法c，将不同行为者所依赖的代码强凑到了一起，有可能原始a方法的修改而合并后的a没有修改就会影响整个方法。
解决方案就是将每一种方法都需要将相关函数分成不同的类，每一个类都分别容纳了一组作用于相同作用域的函数，而该作用域之外，它们各自的私有函数是互相不可见的。
开闭原则
一个设计良好的计算机系统应该在不需要修改的前提下就可以轻易的被扩展。比方说策略模式就很好的说明了这一原则。
如果软件系统想要更容易被改变，那么其设计就必须允许新增代码来修改系统行为，而非只能靠修改原来的代码。实现方式是通过将系统划分为一系列组件，并且将这些组件间的依赖关系
按层次结构进行组织，使得高阶组件不会因低阶组件被修改而受到影响。
里式替换原则
简单来如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换。
也就是说子类可以扩展父类的功能，但不能改变父类原有的功能。在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。如面向接口编程List list = new ArrayList();
接口隔离原则
主要告诫软件设计师应该在设计中避免不必要的依赖。
使用场合,提供调用者需要的方法,屏蔽不需要的方法.满足接口隔离原则.比如说电子商务的系统,有订单这个类,有三个地方会使用到,
一个是用户,只能有查询方法,
一个是外部系统,有添加订单的方法,
一个是管理后台,添加删除修改查询都要用到.
根据接口隔离原则(ISP),一个类对另外一个类的依赖性应当是建立在最小的接口上.
也就是说,对于用户,它只能依赖有一个查询方法的接口.不能访问到不应该访问的方法.
依赖反转原则
该设计原则指出高层策略性的代码不应该依赖实现底层细节的代码，恰恰相反，那些实现底层细节的代码应该依赖高层策略性的代码。
我们每次修改抽象接口的时候，一定也会去修改对应的具体实现。但反过来，当我们修改具体实现时，却很少需要去修改相应的抽象接口。
所以 我们可以认为接口比实现更稳定。优秀的软件设计师和架构师会花费大量的时间精力去设计接口，以减少未来对其进行改动。也就是说架构上追求稳定，必须使用稳定的抽象接口，少依赖多变的实现类。
****************************************************************
【如果文字看累了，可b站搜索“沙皮狗2021”，用听的方式领略知识的魅力】
传送门 ：https://space.bilibili.com/407643589
【微信公众号】：沙皮狗2021
****************************************************************
