单一职责
强调在逻辑上聚焦,目的明确,在类或方法等粒度上只有一个目的(方法级别功能明确,类中的方法关联性强,类中的方法在大方向上关联的功能明确)
职责明确就会带来职责单一的特性,至于明确的多个职责关联性是不是非常强,要不要定义在同一个类中,那就要看类级别的职责是怎么明确的,或者说据具体情况分析处理
类明确职责范围,方法落实职责范围内的具体单一职责
接口隔离
现象:当前类依赖了某个接口,那么当前类中必须用到了依赖接口声明的所有方法,被依赖的接口中没有冗余的方法,这就是接口隔离(不满足条件的接口需要拆分,剔除接口中冗余的方法)
依赖倒置
核心是面向接口或抽象类编程,所谓倒置是指打破常规,改变面向具体编程的习惯转而面向接口即抽象的规范编程
1.尽量做到抽象依赖抽象,具体依赖抽象
2.流程逻辑基于抽象实现,使用时在给出抽象对应的具体
3.案列:接口依赖的属性使用接口定义,方法定义需要的参数使用接口定义,使用接口确定规范,不限制具体的实现,一定程度上可以复用流程逻辑,减轻扩展压力
里氏替换
指导继承关系的使用,建议在继承关系中只做扩展和新增,避免重写
案列:C继承B,想要重写B的d方法,基于里氏替换原则,基于B类抽取出父类A,A类不包含方法d,B继承A,原有的方法d作为扩展,C类也继承A,自己以扩展的形式定义d方法
里氏替换的目标:使得能使用父类实例对象的地方同样可以使用其子类实例对象,并不影响原有代码逻辑的执行
开闭原则:ocp原则
核心原则,强调的是对扩展开放,对修改关闭
具体实现方案:基于抽象写流程逻辑,方法调用的时候给出抽象对应的具体实现
案列:基于接口定义的规范去实现流程逻辑,方法调用的时候给出接口对应的实现类的实列对象,整个流程逻辑可以正确而有效的跑通
对扩展开放
什么是扩展?扩展就是基于抽象概念衍生出具体的实现,对扩展开放就是说可以方便的基于抽象概念衍生出具体的实现,使用接口或抽象类可以方便的实现
对修改关闭
对修改关闭主要针对的是流程逻辑,流程逻辑基于抽象概念编写,不依赖于抽象概念的具体实现而改变代码逻辑的执行流程,所谓的关闭,就是说给定抽象概念的具体实现后,并不需要修改原有流程逻辑的相关代码部分,却可以达到原本方法定义所需要的运行效果
对修改关闭是最终目标,实现代码流程逻辑复用
迪米特法则
又名最小知道原则,提倡对于直接依赖的抽象数据类型保持最小了解程度即可,避免使用非直接依赖的抽象数据类型
理解:每个类都有属于自己的数据信息,如果其它类需要获取这些数据信息并且只对这些数据信息做分析处理,那就直接将整个分析处理的过程定义在本类里,分析结果作为另一种数据信息对外提供,好处是这个被提取出来的分析过程可以被复用,原本需要分析数据的代码逻辑部分也变得简单易读,分析处理流程只要控制入参和返回值,可以任意优化,不影响其它类的使用,降低了耦合度
该法则启发我转变思想观念
以前:注重数据提供环节,认为只要提供了准确的数据,第三方代码爱怎么分析怎么分析,后期不利于维护
现在:如果发现第三方需要分析自己的数据,尽量把这个分析过程定义在自己的类里,对外直接提供分析结果,同时控制入参,可以随时调整分析逻辑,却不影响第三方类的使用,便于维护,分析流程复用性更高
第二个解释是,陌生的类最好不要以局部变量的方式出现在类的内部
直接朋友类:成员变量,方法的入参定义,出参定义中出现的类
非直接朋友类:依赖特征不符合直接朋友类场景的类(前提是有依赖关系)
第二个理解:当前类A中的某个方法B,有代码片段C,代码片段C不涉及当前类A中的所有成员变量以及当前类A中的所有方法,同时代码片段关联了朋友类D,那代码片段C应该封装到朋友类D里面,当前类A原本的代码片段C使用朋友类D的方法调用替代
合成复用原则(很多资料并不单独列出)
建议避免使用继承关系,尽量使用聚合/合成关系达到继承所需要的效果(继承所需要的效果,侧重指复用父类已经定义好的代码逻辑)
设计原则的核心思想
1.将代码中可能需要变化的点独立出来,避免需要变化的代码部分和相对固定的逻辑部分混杂在一起
2.针对接口编程,而不是针对具体的实现编程
3.为了交互对象之间的松耦合设计而努力
网友评论