如何理解依赖倒置?

发布于: 2020 年 06 月 17 日

一、什么是依赖倒置原则,为什么有时候依赖倒置原则又被称为好莱坞原则?

在软件设计中,如果高层直接依赖低层或抽象依赖与实现,那低层或实现带来的变动,会直接影响的高层或抽象;

为了降低这种影响,我们应该使用接口来隔离变化,高层定义抽象依赖于它,低层对象实现高层定义的抽象;这样将低层具体实现的变化不会影响到高层,这种依赖关系的反转称为依赖倒置;

这种高层定义抽象,需要调用低层时,会根据具体实现动态调用低层,完全不需要低层实现主动查找高层,所以又被称为好莱坞原则,Don't call me, I will call you!

二、请描述一个你熟悉的框架,是如何实现依赖倒置原则的

实现依赖倒置的框架有很多,这里我们可以简单来看Spring是如何使用依赖倒置原则的;

在软件开发中,我们通常需要创建一些无状态具有特定功能或业务函义的类,类与类之间会存在相互依赖的关系,而这些类如果让程序员手工创建这些类,一是过程繁锁,创建代码重复,二是类的生命周期,依赖关系管理复杂;

有没有一种方式,让开发的同学通过约定的行为,即可让类在使用的时候,已自动创建好,开发只需要关注业务中如何使用即可。

Spring Ioc容器解决了上面的问题,通过对运行时类的抽象为 bean,将容器对象抽象在BeanFactory,由BeanFactory负责Bean对象的元信息读取、解析,实例化、初始化、使用、回收等整个生命周期的管理。

这样开发只需要通过简单的注解或xml形式的声明,Ioc容器会自动创建好这些Bean,自动为相互有依赖关系的bean注入依赖,无需人为干涉!

三、请用接口隔离原则优化 Cache 类的设计,画出优化后的类图

如图所示,如果客户端只需使用get、put、delete ,而系统后台控制程序例用reBuild,该如何优化?

优化后:

本周总结:

万事万物皆对象,现实的抽象,可以通过软件形式表述。

软件设计的根源是解决现实问题,将现实问题映射到编程领域,即所谓的问题域;

软件设计的核心正是要解决一个个问题域;问题域分解下来就有了我们的业务模型,业务模型进一步分解,就有了代码模型,和数据模型。

业务模型是怎么活动的,反映在代码模型上,一个好的系统应该是拥抱业务需求的快速迭代的。

这就需要系统拥有很好的扩展性,灵活性,易读,易维护这些特性,而这些最终反映在代码模型体现为,类的组织结构,交互行为、都要具备上述特性。

那如何做一个易读、易维护,扩展性好软件系统呢? 必须要尊循以下设计原则:

开闭原则:不需要修改软件实体,就能够扩展功能

依赖倒置原则: 高层模块不能依赖低层模块,而是大家都依赖抽象

抽象不能依赖实现,而是实现依赖抽象

里式替换原则:任何基类出现的地方都能被其子类替换

接口隔离原则:不要强迫客户依赖它们不需要的方法

用户头像

青莲

关注

还未添加个人签名 2018.07.18 加入

还未添加个人简介

评论

发布
暂无评论
如何理解依赖倒置?