.NET 设计模式的六大原则理论知识

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：尽可能的遵循六大原则来写代码，使你的应用变得健壮，扩展性高，易维护。