标签：需要 容器 获取 dep 增加 不同的 模式 lis 度量
转自
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：尽可能的遵循六大原则来写代码，使你的应用变得健壮，扩展性高，易维护。
标签：需要 容器 获取 dep 增加 不同的 模式 lis 度量
原文地址：https://www.cnblogs.com/KQNLL/p/11876237.html
