标签搜索

设计原则

Pop.Kite
2021-12-25 / 0 评论 / 126 阅读 / 正在检测是否收录...

单一职责

工作中常会看见一个Activity的代码有千余行,每每看见这样的代码都会觉得头大。
单一职责顾名思义,每个模块应该只有一个职责。这里的“只有一个职责”并不是说每个模块只有一个函数(方法),而是说每个模块承担的职责应该是高度相关的,或者说任何一个软件模块都应该只对一类行为负责。
形象一点的例子是Git的代码冲突。常规情况项目一个模块由一个人负责;这里面可以把开发者看作一类方法,因为他们会对模块进行修改;当模块含有多个类别的方法(多个开发者),那么一个方法的修改(一个开发者修改代码),就可能其他类的方法(其他开发者)产生影响,从而出现冲突。

现在的台式电脑如果出了故障是很好维修的,内存、硬盘、CPU、主板等组件可以随意替换。这里的内存硬盘等组件,就是单一职责的体现。内存只负责数据的临时读写,硬盘负责持久性读写,CPU负责运算...假使这些组件没有按照单一职责的设计实现而使用高度耦合的设计,比如CPU和硬盘集成在一起,那么CPU坏了也需要将硬盘换掉。
单一职责符合人的认知常识,有助于提高内聚,降低耦合。听上去简单,但是实现上并不简单,如何划分不同职责,需要开发人员有一定的分析设计能力。

接口隔离

接口隔离,意为 实现 不应该依赖于 其 不需要的方法。
画个图
[图片]
类A依赖于接口中的Function1和Function3,A+是该依赖的实现;
类C依赖于接口中的Function1、Function2和Function4,B+是该依赖的实现。
由图可见,类A虽然依赖于接口,但是并不依赖于接口中的Function2和Function4,同理类B也一样,这就不符合接口隔离的原则,因为A+和B+实现了不需要的方法。
因此我们可以将接口细分,实现接口隔离:
[图片]
接口隔离原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中,将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中,依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”,通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。
说到这里,很多人会觉的接口隔离原则跟之前的单一职责原则很相似,其实不然。其一,单一职责原则原注重的是职责;而接口隔离原则注重对接口依赖的隔离。其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口接口,主要针对抽象,针对程序整体框架的构。 采用接口隔离原则对接口进行约束时,要注意以下几点:

  • 接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。
  • 为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。
  • 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。 运用接口隔离原则,一定要适度,接口设计的过大或过小都不好。设计接口的时候,只有多花些时间去思考和筹划,才能准确地实践这一原则。
感觉这个不太常用,会导致Project很乱

里氏替换

里氏替换原则通俗来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能

迪米特原则

//TODO

合成复用

//TODO

依赖倒置

模块的实现不应该相互依赖,而应该依赖于抽象。
面向接口编程,不要面向实现编程。

开闭原则

//TODO

0

评论 (0)

取消