前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >深入理解DIP:依赖倒置原则

深入理解DIP:依赖倒置原则

原创
作者头像
北洋
发布2023-12-13 09:51:35
1300
发布2023-12-13 09:51:35
举报
文章被收录于专栏:北洋csdn北洋csdn

solid之isp:接口隔离原则

scp告诉我们应该保证改变只能有一个来源:自己负责的功能发生改变;

ocp告诉我们开闭原则,对扩展开放对修改关闭提出了一个更严格的设计:程序不修改,新增功能就是添加新代码而不是在旧代码里面修改,要做到这个 也是要很好的进行抽取共通的逻辑,然后把变化的部分抽取出来做扩展,旧的核心的部分是稳定的。

lsp告诉我们应该要正确的设计继承关系;子类在行为上可以完全替换父类是is a的关系(好的is a关系就是父类有的行为子类也都有)。在使用者的角度讲可以忽略子类类型。代码中表现出来的就是 不需要区分运行时的类型做特殊处理,行为上能够完全进行替换

isp 接口隔离原则 告诉我们正确设计接口,不应该强迫使用者使用自己不需要的接口。接口应该只负责自己关心的事情,隔离那些不属于自己的行为;如果一个接口 没有很好的进行隔离那么就会有很多不是自己的方法,接口的方法就会变得臃肿。如果接口很臃肿,那么应该要想想lsp原则,是不是负责了不是自己的行为,没有很好的分离关注点。

所有的设计原则都有个共性就是 要分离关注点,scp,ocp和isp都是分离关注点这个原则在设计类,方法,接口时的核心思想。类违反了这个原则就会导致类会频繁的发生改变;方法违反了这个原则,接口违反了这个原则就会导致自己的接口变得很臃肿

抽取共通逻辑

solid设计原则之 dip:依赖倒置原则

  • 定义:

高层模块不应该依赖于底层模块,二者应该依赖于抽象。

抽象不应该依赖于细节,而细节应该要依赖于抽象。

  • 理解:
  • 高层不应该依赖于底层模块,为什么?我们都知道 设计程序是为了更好的扩展程序。因此需要将经常变动的部分抽取出来,让高层关注稳定的抽象部分。

高层如果依赖于具体的底层模块实现:

首先一是不符合ocp:高层模块关注了不应该关心的点:底层提供的具体实现细节;高层关注的不应该是底层的具体实现,更合理的做法应该是关注底层模块很够提供 给高层 所关心的能力。

二是不符合scp,开闭原则。因为底层模块的实现很容易发生变动和修改;高层如果依赖了底层具体的类,也就同样需要进行修改,而scp是对修改关闭的。更合理的做法应该是 提供高层关心的行为接口,之后替换一个实现只需要在新的一个接口实现即可,不需要修改高层模块的代码。

这都是因为没有很好的分离关注点造成的,高层关心的是底层提供的能力接口行为,而不是底层的具体实现。修改方法也就是 抽象出底层模块给高层提供的能力,让高层依赖这个抽象接口。

之所以叫依赖倒置是因为依赖于具体的底层实现时,底层发生变动高层也需要变动,高层依赖底层;而抽象出接口后,是底层的实现细节需要依赖于 高层提供的抽象接口。

  1. 抽象不应该依赖细节,这是从设计的角度看的,不应该为了抽象而抽象(依赖于细节的抽象本质上还是细节不是抽象)而是需要结合具体的业务 思考到底该抽象哪些东西?

上面将高层模块依赖的是抽象的接口,但是最终运行时还是要依赖于具体的类,那么如何给高层模块传递具体的实现类呢?

组织这些具体的类给到高层模块是 di容器做的事情,正是因为遵循了dip的设计原则,才有将类注入的需求,才会出现di容器,ioc容器。

我正在参与2023腾讯技术创作特训营第四期有奖征文,快来和我瓜分大奖!

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • solid之isp:接口隔离原则
  • solid设计原则之 dip:依赖倒置原则
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档