设计模式-六大原则

设计模式的六大原则

• 1. 单一职责原则（Single Responsibility Principle）
• 2. 里氏替换原则（Liskov Substitution Principle）
• 3. 依赖倒置原则（Dependence Inversion Principle）
• 4. 接口隔离原则（Interface Segregation Principle）
• 5. 迪米特法则 （Law Of Demeter）
• 6. 开闭原则 (Open Closed Principle)

单一职责原则

Single Responsibility Principle

• 定义1:一个类只负责一个功能领域中的相应职责
• 定义2:就一个类而言，应该只有一个引起它变化的原因。
• 通俗的说，即一个类只负责一项职责。

提示

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验—只有熟悉业务，才能做好设计

案例

动物的故事

多分支的Animal该如何设计
都放在一个类---需要各种判断+分支---肯定不稳定，有很多个原因让他变化---违背了单一职责---拆分成多个类(chicker cow fish)---每个类就都稳定了，都单一职责了同一父类多个类型，其实应该拆开写，而不是都塞在一个类---满足单一职责

银行客户端

Client--->
利率要变，得改类，说明职责不单一---封装利率获取的逻辑到别的类账号验证要变，得改类，说明职责不单一---封装到别的类里面—UserCheckService一个类的多个动作，交给别的类去封装，只负责调用---满足单一职责，增强稳定

心得

• 1 如果类型足够简单，可以在类级别去违背单一职责
• 2 如果方法足够简单，可以在方法级别去违背单一职责
• 3 如果类型复杂了，方法逻辑多了，建议遵循单一职责原则
• 4 一个方法，不超过50行(编码建议)
• 5 一个类，不超过300行(编码建议)

优缺点

优点:

• 1 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
• 2 提高类的可读性，提高系统的可维护性；
• 3 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
  

缺点：

• 1 拆多了零碎，不好管理，不好使用，成本高

提示

有所得必有所失，设计师做的，就应该是扬长避短，灵活应用

场景

• 方法级别的单一职责原则：一个方法只做好一件事儿—职责拆分成小方法、接受输入-业务计算-数据操作-日志、分支逻辑拆分--源码：父类方法DoS(写校验)-DoSCore(核心业务)
• 类级别的单一/WebCore
• 项目级别的单一职责原则：项目的职责要清晰—Client、Manager、职责原则：一个类只做好一件事儿—源码：scheme-schemeprovider-handler
• 类库级别的单一职责原则：一个类库做好一件事儿—DAL/BLL/Core/PayCoreBackgroudJob
• 系统级别的单一职责原则：通用系统拆分---IP库/日志中心/在线统计

里氏替换原则

Liskov Substitution Principle

• 定义1：如果对每一个类型为 T1的对象 o1，都有类型为T2 的对象o2，使得以T1定义的所有程序 P 在所有的对象 o1 都代换成o2 时，程序P 的行为没有发生变化，那么类型 T2 是类型T1 的子类型。

• 定义2：所有引用基类的地方必须能透明地使用其子类的对象(继承就是父类出现的都可以用子类，透明是要求行为无变化)里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象

• 里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象

知识点同步

• 1 虚方法：调用的是子类-是以右边类型为准-以override为准---所以一定得有有个关键字，virtual/abstract
• 2 抽象方法：调用的是子类-是以右边类型为准-以override为准---所以一定得有有个关键字，virtual/abstract
• 3 普通方法：调用的是父类-是以左边类型为准-是以编译期为准，因为二次也不知道运行时类型，所以要提前指定

案例

People

• 1 父类有的，子类是必须有的：否则就断掉继承 People-Japanese
• 2 子类可以有自己的属性和行为：People-Chinese-Hubei
• 3 父类实现的东西，子类就不要再写了：Chinese-Hubei的SayHi，写了可能造成不同的行为---如果预期变化，就加上virtual/abstract
• 4 声明属性、字段、变量，尽量声明为父类：当然啦

总结

• 1 尽量声明的时候用父类，而不是具体子类(跟依赖倒置很想)
• 2 子类不要篡改父类的行为，或者virtual/abstract

依赖倒置原则

Dependence Inversion Principle

• 定义:设计代码结构时，高层模块不应该依赖低层模块，二者都应该依赖其抽象。简单说：依赖抽象，而不是依赖细节
• 抽象：抽象类/接口—包含没有实现的
• 细节：具体的类---所有的元素都是确定的
• 抽象不应该依赖细节，细节应该依赖抽象。通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且能够降低修改程序所造成的风险。

案例

学生-手机

Student Play 手机
依赖细节(具体手机)，新增手机都需要修改Student---不合理依赖抽象(AbstractPhone),新增的手机都可以用，只要实现了这个抽象类1 一个方法应对更多类型
2 支持扩展新增，保持稳定性
层级多了，依赖细节，一个改动会影响一连串---水波效应依赖抽象，类的改动影响就不会扩散

类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

分析

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。(插头(可以各种造型各种材质)-插排---车子轮胎-17寸18寸19寸—接口大小) 以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。

抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

建议

1 低层模块尽量都要有抽象类或接口，或者两者都有
2 变量的声明类型尽量是抽象类或接口
3 使用继承时遵循里氏替换原则(避免埋雷)

依赖倒置原则的核心就是要我们面向抽象/接口编程，理解了面向抽象/接口编程，也就理解了依赖倒置。

各种工厂的面向抽象---80%的设计模式都跟面向抽象有关现代化开发
IOC已内置—无处不在的IOC---就得有抽象

接口抽象类选择问题

抽象类： 可以包含具体实现---约束+实现
接口： 不能包含具体实现---约束
C#8.0变化
1 方法可以声明public 也可以protected，但不能是private
2 字段还是不能声明
3 以前委托和类不能声明，现在都可以声明了
4 以前不能有具体实现，现在也可以有了
这个有没有意义？
有，而且是颠覆性的—以前都说接口不能变，现在可以直接增加实现---这对有的设计模式就会产生冲击
还需要抽象类吗？
还是需要的，抽象类是 is a
而接口还是can do

抽象类：（父类只有一个） 继承+约束： 其实为了继承，约束是副业 is a---抽象类表述的对象
接口： （接口可以多个） 只是做约束 can do，就可以跨不同类型 ----接口表述的是行为，以及规则
不是语法上的问题，而是语义上的问题

经验

C#8.0后，接口允许有默认实现，会改变很多认知
选择还是以：
抽象类表述的对象
接口表述的是行为和规则
更多时候，选择接口就对了，除非有代码想复用(值得商榷)

接口隔离原则

Interface Segregation Principle

• 定义：客户端不应该依赖它不需要的接口
• 类间的依赖关系应该建立在最小的接口上

案例

手机-相机

手机：打电话 发短信 看电影 上网 玩游戏 拍照 拍视频导航 支付
平板： 看电影 上网 玩游戏 拍照 拍视频
电视： 看电影 上网 玩游戏
相机： 拍照 拍视频
1 接口太大：不需要的功能也得实现--不合理
2 接口太小：接口众多，还会出现一个对象实现多接口，但不能用3 接口合并：
一定在一起的，要合并(上网-玩游戏 拍照-拍视频)； 不需要对外暴露，只暴露一个(一个动作 多个步骤导航---定位-计算路线-语音播报)
通过继承来组合接口，定制大接口

总结

• 1 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是事实，但是如果过小，则会造成接口数量过多，使设计复杂化，所以一定要适度。
• 2 接口细节屏蔽(导航---定位-计算路线-语音播报)
• 3 通过接口继承来组合接口

和SRP区别

接口隔离和单一职责的区别：

• 其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。
• 其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口，主要针对抽象，针对程序整体框架的构建。

迪米特法则

Law Of Demeter

• 定义:迪米特法则（Law of Demeter）又叫作最少知识原则（The Least Knowledge Principle），一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话。英文简写为: LOD。
• 一个对象应该对其他对象保持最少的了解。
• 类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

案例

学校-班级-学员

1 去掉内部依赖：学校不要直接管student，也不关心细节(BCL基类库类型除外)
2 降低访问修饰符：避免暴露太多细节
3 属性变方法：也是为了保护，可以扩充逻辑

分析

目标都是为了低耦合，高内聚。
耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部

引入

程序对象的直接朋友太多，还可能会引入一个中介，来完成通信，等于是把直接的朋友给变成间接的朋友 比如：一个人和另一个人聊天，发消息 收消息 选择对象 通过中介来发消息 收消息
门面模式
中介者模式

应用范围

1 小到类与类之间：避免跟局部变量交互
2 到类库和类库之间，三层之间：UI-BLL-DAL，UI和DAL不要通信3 大到系统和系统之间：调用用户数据，只能找用户服务，不能找数据库

开闭原则

Open Closed Principle

• 定义:一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
• 只是一个目标，被称之为总则
• 修改：修改现有代码(类-方法)
• 扩展：增加代码(类-方法)

由来

面向对象语言是一种静态语言，最害怕变化，会波及很多东西，需要全面测试最理想就是新增类，对原有代码没有改动，原有的代码才是可信的

开闭原则只是一个目标，并没有任何的手段，也被称之为总则
其他5个原则的建议，就是为了更好的做到OCP
开闭原则也是面向对象语言开发一个终极目标

案例

学生学习

1 学生学习，需要增加个公开课的分支，是修改方法增加判断，换成新增一个方法--甚至换成新增一个类----从修改变新增

2 学生学习，需要增加个额外的动作，是修改方法，还是新增方法，或者子类override ----从修改变新增

代码升级顺序

提示

满足OCP的程度排序：
1 修改配置—IOC/工厂使用配置文件
2 增加dll—依赖抽象+反射
3 增加class--
4 增加方法—
5 修改方法
遵循OCP，也会带来很多成本
SRP—为了少修改，多增加
LSP---用父类，减少修改
DIP---使用抽象
LOD---减少修改
ISP---小一点，稳定点

总结

提示

这代表一个系统设计时，对6大原则的一个完成度1234都是正常的
1 第5个有问题，兼而有之，都没照顾好
2 第6个也不好，过犹不及，太夸张了
设计模式六大原则，也只是指导性原则
努力遵循，程序可以更具备扩展性
可以违背，一切为了目标
具体的体会，还需要更多的设计模式来验证