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

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

1、单一职责原则

2、里氏替换原则

3、依赖倒置原则

4、接口隔离原则

5、迪米特法原则

6、开闭原则

 一、单一职责原则

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

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

1、情况

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

C#.Net学习笔记——设计模式六大原则_第1张图片

运行方法

C#.Net学习笔记——设计模式六大原则_第2张图片

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

C#.Net学习笔记——设计模式六大原则_第3张图片

 2、简单案例

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

C#.Net学习笔记——设计模式六大原则_第4张图片

C#.Net学习笔记——设计模式六大原则_第5张图片C#.Net学习笔记——设计模式六大原则_第6张图片C#.Net学习笔记——设计模式六大原则_第7张图片C#.Net学习笔记——设计模式六大原则_第8张图片

3、优点

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

阅读简单,易于维护。

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

方便代码重用。

4、缺点

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

5、使用时机

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

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

6、举例

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

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

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

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

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

二、里氏替换原则

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

继承、多态          

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

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

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

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

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

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

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

C#.Net学习笔记——设计模式六大原则_第9张图片C#.Net学习笔记——设计模式六大原则_第10张图片C#.Net学习笔记——设计模式六大原则_第11张图片

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

C#.Net学习笔记——设计模式六大原则_第12张图片

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

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

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

基础:

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

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

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

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

4、只与直接的朋友通信

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

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

学校的管理方式:

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

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

参考示例:

C#.Net学习笔记——设计模式六大原则_第13张图片C#.Net学习笔记——设计模式六大原则_第14张图片C#.Net学习笔记——设计模式六大原则_第15张图片

四、依赖倒置原则

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

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

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

C#.Net学习笔记——设计模式六大原则_第16张图片C#.Net学习笔记——设计模式六大原则_第17张图片C#.Net学习笔记——设计模式六大原则_第18张图片C#.Net学习笔记——设计模式六大原则_第19张图片

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

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

C#.Net学习笔记——设计模式六大原则_第20张图片

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

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

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

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

五、接口隔离原则

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

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

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

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

C#.Net学习笔记——设计模式六大原则_第21张图片

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

六、开闭原则

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

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

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

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

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

你可能感兴趣的:(设计模式)