C#.Net学习笔记——设计模式六大原则

***************基础介绍***************

1、单一职责原则

2、里氏替换原则

3、依赖倒置原则

4、接口隔离原则

5、迪米特法原则

6、开闭原则

一、单一职责原则

**举例:**类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。

**总结:**一个类只负责一件事

1、情况

这里我们封装了一个动物类,写上两个方法,呼吸和行为。

运行方法

这里我们构造函数传入"鱼"的话,这样就不符合逻辑了

2**、简单案例**

我们把Animal类 抽象为父类,然后把鸟、鱼等动物作为子类,去继承Animal。每个动物类内去重写各自的方法。互不影响。这就是单一职责原则

3、优点

一个类只负责一件事,拆分之后,职责变得单一。

阅读简单,易于维护。

扩展升级,减少修改,直接增加类。

方便代码重用。

4、缺点

类变多了,上端需要了解更多的类

5、使用时机

衡量着使用:如果类相对稳定,拓展变化少,而且逻辑简单,违背单一职责也没关系。 一个类不要让它太冗长

如果不同的职责,总是一起变化的,这种是一定要分开的。

6、举例

方法:方法多个分支,还可能拓展变化,最好分开多个方法

类:接收输入------数据验证------逻辑计算------数据库操作------日志,方便维护升级

接口:也会把不同的功能接口独立开来

类库:把项目拆分多个类库,重用------方便维护

项目:一个Web解决所有问题:客户端;管理后台;定时服务;远程接口;

二、里氏替换原则

**基本:**任何使用基类的地方,都可以透明的使用其子类

继承、多态

继承:通过继承,子类拥有父类的一切属性和行为,任何父类出现的地方,都可以用子类来代替

1、子类必须完全实现父类的方法,如果子类没有父类的某项东西,就断掉继承

2、子类可以有父类没有的东西,所以子类出现的地方,不一定能用父类来代替

3、透明(安全),父类的东西换成子类后不影响程序。

4、尽量不要new父类写完的方法,最好选择使用virtual和override的方式,避免埋雷

声明变量、参数、属性、字段最好都是基于基类的。

小题目:抽象类的父类有三个方法,Test01是普通方法,Test02是虚方法,Test03是抽象方法。子类继承了父类,重写了这3个方法。在实例化了子类后调用三个方法,调用的会是谁的方法?

答案是**:父类、子类、子类**

1、普通方法由左边决定,编译时决定

2、虚方法和抽象方法由右边决定,运行时决定

三、迪米特法则(最少知道原则)

基础:

1、一个对象应该对其他对象保持最少的了解。

2、面向对象------类------类与类之间会有交互------功能模块------系统

3、高内聚,低耦合。高度封装,类与类之间减少依赖

耦合关系:依赖、关联、组合、聚合 继承、实现接口。

4、只与直接的朋友通信

5、去掉内部依赖------降低访问修饰符

举例:我们有三个类,分别是学校类(School)、课室类(Class)和学生类(Student),课室中有学生,学生和学校没有直接联系,则学生是学校的依赖(间接关系)

学校的管理方式:

1、学校让班级自己去管理学生(符合迪米特法则)

2、学校直接管理所有学生(不符合迪米特法则)

参考示例:

四、依赖倒置原则

1、基础:上层模块应该依赖于底层模块,二者应该通过抽象依赖

依赖抽象,而不是依赖细节

小案例:我有一个手机基类,子类分别有IPhone类和HuaWei类,还有一个Student学生类,学生类可以玩IPhone和HuaWei手机,因此我们写了两个方法,可以传入两种手机的参数。但是如果我们希望后续给学生拓展更多的手机,那我们就要写更多的方法?

这种其实在方法里直接传入手机子类,其实算是依赖细节

其实我们可以写一个方法,参数为手机基类**(依赖抽象)**:

1、依赖抽象更具有通用性,而且具备拓展性。

2、细节是多变的,抽象是稳定的;系统架构基于抽象来搭建,会更加具备拓展性

3、面向抽象编程,底层模块里面尽量都有抽象类/接口

4、在声明参数/变量/属性的时候,尽量都是 接口/抽象类

五、接口隔离原则

1、基础:客户端不应该依赖它不需要的接口;

一个类对另一个类的依赖应该建立在最小的接口上;

实现一个接口的时候,只需要自己必须的功能;

小案例:还是用上边手机的案例,我们刚刚通过抽象类来描述我们的手机,那对于我们手机的功能我们可以使用接口,抽象类主要用于是什么,接口主要用于干什么。

这里我写了一个接口,只需要继承这个接口,我们的手机就有打电话、上网、玩游戏等功能。但假如有一天我们需要假如一台老人机,而老人机并没有上网、玩游戏等功能,而我们这个接口就必须实现接口内的所有方法,这时候就不太合适了。最好的方法是把接口隔离开,比如所有手机都可以打电话,发短信,那么打电话和发短信就可以单独写一个接口,其他智能机才有的功能另外写一个接口。我们需要用什么接口就继承什么接口即可。

六、开闭原则

1、基础:1、对拓展开发,对修改关闭

2、如果有功能拓展变化的需求,希望是增加类而不是修改。

3、修改会影响原有功能,引入错误

4、增加类就不会影响原有的东西

5、原则的原则,五大原则是手段,开闭原则是目标

相关推荐
吾与谁归in20 分钟前
【C#设计模式(13)——代理模式(Proxy Pattern)】
设计模式·c#·代理模式
吾与谁归in21 分钟前
【C#设计模式(14)——责任链模式( Chain-of-responsibility Pattern)】
设计模式·c#·责任链模式
闲人一枚(学习中)29 分钟前
设计模式-创建型-原型模式
设计模式
Iced_Sheep1 小时前
干掉 if else 之策略模式
后端·设计模式
哪 吒8 小时前
最简单的设计模式,抽象工厂模式,是否属于过度设计?
设计模式·抽象工厂模式
Theodore_10228 小时前
4 设计模式原则之接口隔离原则
java·开发语言·设计模式·java-ee·接口隔离原则·javaee
转世成为计算机大神11 小时前
易考八股文之Java中的设计模式?
java·开发语言·设计模式
小乖兽技术12 小时前
23种设计模式速记法
设计模式
小白不太白95014 小时前
设计模式之 外观模式
microsoft·设计模式·外观模式
小白不太白95014 小时前
设计模式之 原型模式
设计模式·原型模式