***************基础介绍***************
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、原则的原则,五大原则是手段,开闭原则是目标