单一职责原则
对于一个类而言，有且仅有一个引起他变化的原因或者说，一个类只负责一个职责
如果一个类承担的职责过多，那么这些职责放在一起耦合度太高了，一个职责的变化可能会影响这个类其他职责的能力。
所以我们在做软件设计的时候，要发现职责，并且把这些职责互相分开
例子1
对于看书这件事情，用手机看书和直接看纸质书相比，肯定纸质书的效率要高一些。
因为手机的职责太多了，接打电话、听歌、看电视剧等等，我们在看书的时候，可能收别的职责的影响。
而纸质书，只有一个职责，沉浸式读书。
例子2
电脑机箱中，由CPU、内存、硬盘、显卡、主板等等。
假设我们的CPU、内存、应该、显卡是高层模块，电脑中应该叫易插拔，都插到主板中。
对于电脑这个主体而言，就符合单一职责原则，内存条坏了，不会影响CPU、磁盘和主板。
开闭原则
对扩展开发，对修改封闭【多扩展、少修改】
当我们面对新需求的时候，对程序的修改只是通过增加代码的方式，而不用去修改已有的代码。
这样做我们程序变得更加，可扩展、可维护、可服用、灵活性。
例子
假设现在我们由两个模块，一个是高层模块（做业务逻辑模块），一个底层模块（数据库模块）。
数据库的一些常见操作比如：增删改查，但是我们使用的数据库可以是MySQL、SQLServer、Postgresql等等。
那么如果做到开闭原则呐，抽象出一个类，如果新加了数据库去继承这个类，然后自己去实现增删改查接口。
这样就做到了对扩展开发，对修改封闭了。
依赖倒置原则
高层模块不应该依赖于底层模块，他们都应该依赖于抽象
我们要针对接口编程，而不是针对实现编程
例子1
电脑举例，CPU、内存、硬盘、显卡都应该依赖于抽象接口，而不是依赖于具体的主板。
如果依赖于具体的主板，那么主板坏了，这些高层的设备都用不了了，这样设计显然不合理。
例子2
还是上面那个例子，高层模块（业务逻辑层）和底层模块（数据库层）都不应该互相依赖，而是依赖于抽象。
高层模块 => 抽象 => 低层模块
抽象其实就是基类，底层模块是子类。
MySQL、SQLServer、PostgreSQL都有增删改查操作，假设有一天要用到别的数据库
只需要再创建一个类，继承抽象去实现这些接口，对于高层模块而言，不需要任何的改变（或者只需要改变new的对象而已）
里氏替换原则
子类必须能够替代父类
例子
假设鸟是父类，那么鸵鸟和企鹅能继承于鸟类吗？
如果按照初中老师讲的，鸵鸟和企鹅虽然不能飞，但是属于鸟类。
但是再我们编程的世界里面，如果鸵鸟和企鹅可以继承鸟类，这是不合理的，违反了里氏替换原则。
还是举一个例子，他们的高层模块 => 抽象 => 低层模块
如果抽象中要使用的方法就是鸟的会飞的方法，但是我们底层模块是鸵鸟，根本不会飞，这样就会产生严重的错误
所以里氏替换原子是实现依赖倒置原则的基础