1. 单一职责原则（SRP）（Single Responsibility Principle）
2. 里氏替换原则（LSP）（Liskov Substitution Principle）
3. 依赖倒置原则（DIP）（Dependence Inversion Principle）
4. 接口隔离原则（ISP）（Interface Segregation Principle）
5. 迪米特原则（LOD）（Law Of Demeter）
6. 开闭原则（OCP）（Open Closed Principle）
1：单一职责原则（一个类只做一件事）
应用场景：
类T负责两个不同的职责：P1职责，P2职责。当P1需求发生变法时而需要修改类T时，就有可能导致原本运行正常的P2发生故障。
遵循单一原则，把P1跟P2分成两个类，每个类只关注一件事情避免因为需求的修改而引发不必要的故障
什么情况下可以违背单一职责原则：
只要逻辑足够简单，就可以在方法级别上违背单一职责原则
如果一个类足够简单，方法够少，就可以在类级别上违背单一职责原则
杂话：各种级别（方法/类/接口/类库/项目/系统）
优点：
1 类逻辑变得简单
2 代码稳定，可扩展性高
缺点：
1 代码会变多
2：里氏替换原则（任何使用基类的地方，其子类都可以透明的使用（继承，多态））
如果子类不能拥有父类的全部属性和行为，断掉继承
如果子类要修改父类的行为，使用override/virtual
总结来说，里氏替换原则就是规范了继承的使用
3：依赖倒置原则（上层模块不直接依赖下层模块，二者应通过抽象依赖（抽象类/接口类））
依赖抽象（抽象类/接口类），而不是依赖细节（实现类）
相对于细节，依赖抽象更稳定
基于抽象的架构，更稳定
杂谈：经常听到的几个词
1 控制反转（IOC）：把依赖交给第三方容器来完成 （目的）
2 依赖注入（DI）：实现控制反转的一种手段 （行为）
4：接口隔离原则（客户端不应该依赖于它不需要的接口，一个类对另一个类的的依赖应该建立在最小的接口上）
不要使用大而全的接口，这样导致实现不需要的方法
也不能拆分的太细，这样会导致使用不便
关于接口隔离原则，具体情况还需要根据业务需求来定，没有一个同一标准，该拆该合，都得需要自己度量
5：迪米特法则（最少知道原则）（一个对象只于关系最密切的朋友进行通讯，高内聚，低耦合）
类于类之间，要避免不必要的依赖
学校，老师，班级，学生四个类
学校只与老师通讯，老师只跟班级通讯，不要学校在关联老师的同时，又关联班级，这样会增加依赖、
场景：老师类中有一个班级的集合，班级类中有一个学生的集合
错误做法：在老师类中写一个方法，遍历出所有班级，在遍历中，又根据班级遍历出所有学生（这种写法虽然很爽，但是增加了不必要的依赖）
正确做法：在老师类中写一个方法，在班级类中写一个方法，老师类中遍历出所有班级，在遍历中在根据班级调用班级类中自身的方法获取所有的学生（减少了不必要的依赖）
杂谈：类与类的关系
纵向关系：继承 实现
横向关系：依赖（方法内部） 关联 组合 聚合（后三个：方法返回/参数 属性）
6：开闭原则（开放扩展，关闭修改）
没有任何的指导意义，只能算是一个愿景，架构的最理想状态
其他五个原则，都是为了辅助开闭原则，从而达到真正的理想状态
总结
1：六大原则并不是指具体的技术或者应用，而是一个指导性的原则，如何遵循六大原则需要自己度量，相当于一个建议，并不一定必须遵守六大原则，根据业务需求，自己做取舍
2：真正的业务需求中，往往会出现遵循了这个原则，却违反了另一个原则，具体侧重哪个原则，还要根据业务需求来定，不要盲目的追求。
3：尽可能的遵循六大原则来写代码，使你的应用变得健壮，扩展性高，易维护。