精华内容
下载资源
问答
  • 倒置自己
    2022-03-19 14:58:51

    依赖倒置原则

    1 依赖倒置原则的定义

    依赖倒置原则(Dependence Inversion Principle,DIP)这个名字看着有点别扭,“依赖”还“倒置”,这到底是什么意思?依赖倒置原则的原始定义是:

    High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

    翻译过来,包含三层含义:

    ● 高层模块不应该依赖低层模块,两者都应该依赖其抽象;

    ● 抽象不应该依赖细节;

    ● 细节应该依赖抽象。

    高层模块和低层模块容易理解,每一个逻辑的实现都是由原子逻辑组成的,不可分割的原子逻辑就是低层模块,原子逻辑的再组装就是高层模块。那什么是抽象?什么又是细节呢?在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现

    类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是:

    ● 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关

    系,其依赖关系是通过接口或抽象类产生的;

    ● 接口或抽象类不依赖于实现类;

    ● 实现类依赖接口或抽象类

    更加精简的定义就是“面向接口编程”——OOD(ObjectOriented Design,面向对象设计)的精髓之一。

    2 依赖倒置原则的意义

    采用依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。

    证明一个定理是否正确,有两种常用的方法:一种是根据提出的论题,经过一番论证,推出和定理相同的结论,这是顺推证法;还有一种是首先假设提出的命题是伪命题,然后推导出一个荒谬、与已知条件互斥的结论,这是反证法。我们今天就用反证法来证明依赖倒置原则是多么优秀和伟大!

    • 论题:依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。

    • 反论题:不使用依赖倒置原则也可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性

    我们通过一个例子来说明反论题是不成立的。现在的汽车越来越便宜了,一个卫生间的造价就可以买到一辆不错的汽车,有汽车就必然有人来驾驶,司机驾驶奔驰车的类图如图3-1所示。
    司机驾驶奔驰车的类图

    奔驰车可以提供一个方法run,代表车辆运行,实现过程如代码清单3-1所示。

    代码清单3-1 司机源代码

    public class Driver { 
     //司机的主要职责就是驾驶汽车
     public void drive(Benz benz){
     benz.run();
     }
    

    司机通过调用奔驰车的run方法开动奔驰车,其源代码如代码清单3-2所示。

    代码清单3-2 奔驰车源代码

    public class Benz {
     //汽车肯定会跑
     public void run(){
     System.out.println("奔驰汽车开始运行...");
     }
    }
    

    有车,有司机,在Client场景类产生相应的对象,其源代码如代码清单3-3所示。

    代码清单3-3 场景类源代码

    public class Client {
     public static void main(String[] args) {
     Driver zhangSan = new Driver();
     Benz benz = new Benz();
     //张三开奔驰车
     zhangSan.drive(benz);
     }
    }
    

    通过以上的代码,完成了司机开动奔驰车的场景,到目前为止,这个司机开奔驰车的项目没有任何问题。我们常说“危难时刻见真情”,我们把这句话移植到技术上就成了“变更才显真功夫”,业务需求变更永无休止,技术前进就永无止境,在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头:张三司机不仅要开奔驰车,还要开宝马车,又该怎么实现呢?麻烦出来了,那好,我们走一步是一步,我们先把宝马车产生出来,实现过程如代码清单3-4所示。

    代码清单3-4 宝马车源代码

    public class BMW {
     //宝马车当然也可以开动了
     public void run(){
     System.out.println("宝马汽车开始运行...");
     }
    }
    

    宝马车也产生了,但是我们却没有办法让张三开动起来,为什么?张三没有开动宝马车的方法呀!一个拿有C驾照的司机竟然只能开奔驰车而不能开宝马车,这也太不合理了!在现实世界都不允许存在这种情况,何况程序还是对现实世界的抽象,我们的设计出现了问题:司机类和奔驰车类之间是紧耦合的关系,其导致的结果就是系统的可维护性大大降低,可读性降低,两个相似的类需要阅读两个文件,你乐意吗?还有稳定性,什么是稳定性?固化的、健壮的才是稳定的,这里只是增加了一个车类就需要修改司机类,这不是稳定性,这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本,这样的依赖关系谁肯承担!证明到这里,我们已经知道反论题已经部分不成立了。

    注意 设计是否具备稳定性,只要适当地“松松土”,观察“设计的蓝图”是否还可以茁壮地成长就可以得出结论,稳定性较高的设计,在周围环境频繁变化的时候,依然可以做到“我自岿然不动”。

    我们继续证明,“减少并行开发引起的风险”,什么是并行开发的风险?并行开发最大的风险就是风险扩散,本来只是一段程序的错误或异常,逐步波及一个功能,一个模块,甚至到最后毁坏了整个项目。为什么并行开发就有这样的风险呢?一个团队,20个开发人员,各人负责不同的功能模块,甲负责汽车类的建造,乙负责司机类的建造,在甲没有完成的情况下,乙是不能完全地编写代码的,缺少汽车类,编译器根本就不会让你通过!在缺少Benz类的情况下,Driver类能编译吗?更不要说是单元测试了!在这种不使用依赖倒置原则的环境中,所有的开发工作都是“单线程”的,甲做完,乙再做,然后是丙继续……这在20世纪90年代“个人英雄主义”编程模式中还是比较适用的,一个人完成所有的代码工作。但在现在的大中型项目中已经是完全不能胜任了,一个项目是一个团队协作的结果,一个“英雄”再牛也不可能了解所有的业务和所有的技术,要协作就要并行开发,要并行开发就要解决模块之间的项目依赖关系,那然后呢?依赖倒置原则就隆重出场了!

    根据以上证明,如果不使用依赖倒置原则就会加重类间的耦合性,降低系统的稳定性,增加并行开发引起的风险,降低代码的可读性和可维护性。承接上面的例子,引入依赖倒置原则后的类图如图3-2所示。

    请添加图片描述

    建立两个接口:IDriver和ICar,分别定义了司机和汽车的各个职能,司机就是驾驶汽车,必须实现drive()方法,其实现过程如代码清单3-5所示。

    public interface IDriver {
     //是司机就应该会驾驶汽车
     public void drive(ICar car);
    }
    

    接口只是一个抽象化的概念,是对一类事物的最抽象描述,具体的实现代码由相应的实现类来完成,Driver实现类如代码清单3-6所示

    代码清单3-6 司机类的实现

    public class Driver implements IDriver{ 
     //司机的主要职责就是驾驶汽车
     public void drive(ICar car){
     car.run();
     }
    }
    

    在IDriver中,通过传入ICar接口实现了抽象之间的依赖关系,Driver实现类也传入了ICar接口,至于到底是哪个型号的Car,需要在高层模块中声明。ICar及其两个实现类的实现过程如代码清单3-7所示。

    代码清单3-7 汽车接口及两个实现类

    public interface ICar {
     //是汽车就应该能跑
    public void run();
    }
    public class Benz implements ICar{
     //汽车肯定会跑
     public void run(){
     System.out.println("奔驰汽车开始运行...");
     }
    }
    public class BMW implements ICar{ 
     //宝马车当然也可以开动了
     public void run(){
     System.out.println("宝马汽车开始运行...");
     }
    }
    

    在业务场景中,我们贯彻“抽象不应该依赖细节”,也就是我们认为抽象(ICar接口)不依赖BMW和Benz两个实现类(细节),因此在高层次的模块中应用都是抽象,Client的实现过程如代码清单3-8所示

    代码清单3-8 业务场景

    public class Client {
     public static void main(String[] args) {
     IDriver zhangSan = new Driver();
     ICar benz = new Benz();
     //张三开奔驰车
     zhangSan.drive(benz);
     }
    }
    

    Client属于高层业务逻辑,它对低层模块的依赖都建立在抽象上,zhangSan的表面类型是IDriver,Benz的表面类型是ICar,也许你要问,在这个高层模块中也调用到了低层模块,比如new Driver()和new Benz()等,如何解释?确实如此,zhangSan的表面类型是IDriver,是一个接口,是抽象的、非实体化的,在其后的所有操作中,zhangSan都是以IDriver类型进行操作,屏蔽了细节对抽象的影响。当然,张三如果要开宝马车,也很容易,我们只要修改业务场景类就可以,实现过程如代码清单3-9所示。

    代码清单3-9 张三驾驶宝马车的实现过程

    public class Client {
     public static void main(String[] args) {
     IDriver zhangSan = new Driver();
     ICar bmw = new BMW();
     //张三开奔驰车
     zhangSan.drive(bmw);
     }
    }
    

    在新增加低层模块时,只修改了业务场景类,也就是高层模块,对其他低层模块如Driver类不需要做任何修改,业务就可以运行,把“变更”引起的风险扩散降到最低。

    注意 在Java中,只要定义变量就必然要有类型,一个变量可以有两种类型:表面类型和实际类型,表面类型是在定义的时候赋予的类型,实际类型是对象的类型,如zhangSan的表面类型是IDriver,实际类型是Driver。

    我们再来思考依赖倒置对并行开发的影响。两个类之间有依赖关系,只要制定出两者之间的接口(或抽象类)就可以独立开发了,而且项目之间的单元测试也可以独立地运行,而TDD(Test-DrivenDevelopment,测试驱动开发)开发模式就是依赖倒置原则的最高级应用。我们继续回顾上面司机驾驶汽车的例子,甲程序员负责IDriver的开发,乙程序员负责ICar的开发,两个开发人员只要制定好了接口就可以独立地开发了,甲开发进度比较快,完成了IDriver以及相关的实现类Driver的开发工作,而乙程序员滞后开发,那甲是否可以进行单

    元测试呢?答案是可以,我们引入一个JMock工具,其最基本的功能是根据抽象虚拟一个对象进行测试,测试类如代码清单3-10所示。

    代码清单3-10 测试类

    public class DriverTest extends TestCase{
     Mockery context = new JUnit4Mockery();
     @Test
     public void testDriver() {
     //根据接口虚拟一个对象
     final ICar car = context.mock(ICar.class);
     IDriver driver = new Driver();
     //内部类
     context.checking(new Expectations(){{
     oneOf (car).run(); 
     }});
     driver.drive(car);
     }
    }
    

    注意粗体部分,我们只需要一个ICar的接口,就可以对Driver类进行单元测试。从这一点来看,两个相互依赖的对象可以分别进行开发,孤立地进行单元测试,进而保证并行开发的效率和质量,TDD开发的精髓不就在这里吗?测试驱动开发,先写好单元测试类,然后再写实现类,这对提高代码的质量有非常大的帮助,特别适合研发类项目或在项目成员整体水平比较低的情况下采用。抽象是对实现的约束,对依赖者而言,也是一种契约,不仅仅约束自己,还同时约束自己与外部的关系,其目的是保证所有的细节不脱离契约的范畴,确保约束双方按照既定的契约(抽象)共同发展,只要抽象这根基线在,细节就脱离不了这个圈圈,始终让你的对象做到“言必信,行必果”。

    3. 依赖的三种写法

    依赖是可以传递的,A对象依赖B对象,B又依赖C,C又依赖D……生生不息,依赖不止,记住一点:只要做到抽象依赖,即使是多层的依赖传递也无所畏惧!

    对象的依赖关系有三种方式来传递,如下所示。

    3.1 构造函数传递依赖对象

    在类中通过构造函数声明依赖对象,按照依赖注入的说法,这种方式叫做构造函数注入,按照这种方式的注入,IDriver和Driver的程序修改后如代码清单3-11所示。

    代码清单3-11 构造函数传递依赖对象

    public interface IDriver {
        /**
         * 定义动作
         */
        void drive();
    }
    
    public class DriverImpl implements IDriver {
        private IDriver idDriver;
    
        private IDriver idDriver() {
            return idDriver;
        }
    
        private void setIdDriver(IDriver idDriver) {
            this.idDriver = idDriver;
        }
    
        /**构造函数注入*/
        public DriverImpl(IDriver idDriver) {
            setIdDriver(idDriver);
        }
    
        /**司机的主要职责就是驾驶汽车*/
        @Override
        public void drive() {
            idDriver().drive();
        }
    }
    

    3.2 Setter方法传递依赖对象

    在抽象中设置Setter方法声明依赖关系,依照依赖注入的说法,这是Setter依赖注入,按照这种方式的注入,IDriver和Driver的程序修改后如代码清单3-12所示。

    代码清单3-12 Setter依赖注入

    public interface IDriver {
        /**
         * 定义动作
         */
        void drive();
        /**
         * 定义车辆类型
         * @param info 车辆信息
         */
        void setCar(IDriver info);
    }
    
    public class DriverImpl implements IDriver {
        private IDriver idDriver;
        private IDriver idDriver() {return idDriver;}
        private void setIdDriver(IDriver idDriver) {this.idDriver = idDriver;}
        /**司机的主要职责就是驾驶汽车*/
        @Override
        public void drive() {idDriver().drive();}
        /**
         * 描述车辆的相关信息
         * @param info 车辆信息
         */
        @Override
        public void setCar(IDriver info) {setIdDriver(info);}
    }
    

    3.3 接口声明依赖对象

    在接口的方法中声明依赖对象,3.2节的例子就采用了接口声明依赖的方式,该方法也叫做接口注入。

    4 最佳实践

    依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合,我们怎么在项目中使用这个规则呢?只要遵循以下的几个规则就可以:

    • 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备

    这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置。

    • 变量的表面类型尽量是接口或者是抽象类

    很多书上说变量的类型一定要是接口或者是抽象类,这个有点绝对化了,比如一个工具类,xxxUtils一般是不需要接口或是抽象类的。还有,如果你要使用类的clone方法,就必须使用实现类,这个是JDK提供的一个规范。

    • 变量的表面类型尽量是接口或者是抽象类

    很多书上说变量的类型一定要是接口或者是抽象类,这个有点绝对化了,比如一个工具类,xxxUtils一般是不需要接口或是抽象类的。还有,如果你要使用类的clone方法,就必须使用实现类,这个是JDK提供的一个规范。

    • 任何类都不应该从具体类派生

    如果一个项目处于开发状态,确实不应该有从具体类派生出子类的情况,但这也不是绝对的,因为人都是会犯错误的,有时设计缺陷是在所难免的,因此只要不超过两层的继承都是可以忍受的。特别是负责项目维护的同志,基本上可以不考虑这个规则,为什么?维护工作基本上都是进行扩展开发,修复行为,通过一个继承关系,覆写一个方法就可以修正一个很大的Bug,何必去继承最高的基类呢?(当然

    这种情况尽量发生在不甚了解父类或者无法获得父类代码的情况下。)

    • 尽量不要覆写基类的方法

    如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。

    • 结合里氏替换原则使用

    在第2章中我们讲解了里氏替换原则,父类出现的地方子类就能出现,再结合本章的讲解,我们可以得出这样一个通俗的规则: 接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。讲了这么多,估计大家对“倒置”这个词还是有点不理解,那到底什么是“倒置”呢?我们先说“正置”是什么意思,依赖正置就是类间的依赖是实实在在的实现类间的依赖,也就是面向实现编程,这也是正常人的思维方式,我要开奔驰车就依赖奔驰车,我要使用笔记本电脑就直接依赖笔记本电脑,而编写程序需要的是对现实世界的事物进行抽象,抽象的结果就是有了抽象类和接口,然后我们根据系统设计的需要产生了抽象间的依赖,代替了人们传统思维中的事物间的依赖,“倒置”就是从这里产生的。


    依赖倒置原则的优点在小型项目中很难体现出来,例如小于10个人月的项目,使用简单的SSH架构,基本上不费太大力气就可以完成,是否采用依赖倒置原则影响不大。但是,在一个大中型项目中,采用依赖倒置原则有非常多的优点,特别是规避一些非技术因素引起的问

    题。项目越大,需求变化的概率也越大,通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束,可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的,如果设计优良、代码结构清晰,人员变化对项目的影响基本为零。大中型项目的维护周期一般都很长,采用依赖倒置原则可以让维护人员轻松地扩展和维护。

    依赖倒置原则是6个设计原则中最难以实现的原则,它是实现开闭原则的重要途径,依赖倒置原则没有实现,就别想实现对扩展开放,对修改关闭。在项目中,大家只要记住是“面向接口编程”就基本上抓住了依赖倒置原则的核心。

    讲了这么多依赖倒置原则的优点,我们也来打击一下大家,在现实世界中确实存在着必须依赖细节的事物,比如法律,就必须依赖细节的定义。“杀人偿命”在中国的法律中古今有之,那这里的“杀人”就是一个抽象的含义,怎么杀,杀什么人,为什么杀人,都没有定义,只要是杀人就统统得偿命,这就是有问题了,好人杀了坏人,还要陪上自己的一条性命,这是不公正的,从这一点看,我们在实际的项目中使用依赖倒置原则时需要审时度势,不要抓住一个原则不放,每一个原则的优点都是有限度的,并不是放之四海而皆准的真理,所以别为了遵循一个原则而放弃了一个项目的终极目标:投产上线和盈利。作为一个项目经理或架构师,应该懂得技术只是实现目的的工具,惹恼了顶头上司,设计做得再漂亮,代码写得再完美,项目做得再符合标准,一旦项目亏本,产品投入大于产出,那整体就是扯淡!你自己也别想混得更好!


    当年汉高祖刘邦入关后与老百姓约法三章,其中有一条就是:“杀人者死,伤人及盗抵罪。”
    之,那这里的“杀人”就是一个抽象的含义,怎么杀,杀什么人,为什么杀人,都没有定义,只要是杀人就统统得偿命,这就是有问题了,好人杀了坏人,还要陪上自己的一条性命,这是不公正的,从这一点看,我们在实际的项目中使用依赖倒置原则时需要审时度势,不要抓住一个原则不放,每一个原则的优点都是有限度的,并不是放之四海而皆准的真理,所以别为了遵循一个原则而放弃了一个项目的终极目标:投产上线和盈利。作为一个项目经理或架构师,应该懂得技术只是实现目的的工具,惹恼了顶头上司,设计做得再漂亮,代码写得再完美,项目做得再符合标准,一旦项目亏本,产品投入大于产出,那整体就是扯淡!你自己也别想混得更好!


    当年汉高祖刘邦入关后与老百姓约法三章,其中有一条就是:“杀人者死,伤人及盗抵罪。”

    更多相关内容
  • 依赖倒置原则——举例说明Java设计模式中的依赖倒置原则一、前言看官方定义二、举例说明2.1 例子介绍(无聊的可看看,着急的请跳过)2.2 反例2.1.1 反例1(1)类图说明(2)代码说明(3)测试(4)分析优缺点2.1.2 ...

    一、前言

    • 依赖倒置原则也称依赖倒转原则(Dependence Inversion Principle)

    看官方定义

    • 高层模块不应该依赖底层模块,二者都应该依赖其抽象

    • 抽象不应该依赖细节,细节应该依赖抽象

    • 依赖倒置的中心思想是面向接口编程

    • 如果你了解点设计模式,应该理解上面的话,但是如果不了解的话,感觉说的云里雾里的,是不是一脸懵,懵这就对了,那就先看例子吧,会帮助你理解的!

    二、举例说明

    2.1 例子介绍(无聊的可看看,着急的请跳过)

    • 能看下面的类图就看图,能看代码就看代码,我就是简单说一下例子的想法
    • 如果你问身边的人或者看网上的代码都不是自己的思想,如果你没有勇气把公司的代码都用设计模式优化一遍,那就忍着,等你的架构师忍不住的时候再动手,但是如果学完东西不实操很容易就忘记。
    • 那这就需要好的例子了,其实举例也是思想得一部分,懂得多了,就信手拈来,公司中好多人都会跟你说只可意会不可言传,我挺讨厌这句话的,说了等于没说,如果你不想继续当码农,不妨把生活应用于实践,别人问你什么你能用通俗易懂的例子告诉他,你就赢了!
    • 因为我养着一条狗叫麦兜,心里又喜欢着猫,想在多年后一定要养一只布偶或者德文,所以我的很多例子都是很麦兜有关系,设计来源于生活!那下面的例子就是家庭养殖场养殖各种宠物的例子

    2.2 反例

    2.1.1 反例1

    (1)类图说明

    • 先介绍一下这几个类,待会看图理解
      FamilyFarm–>家庭养殖场类,不定时的收养宠物
      DogGrowthProcess–>狗狗成长过程类,记录狗狗从出生到被收养的过程
      ClientTest–>不说了,说多了都是废话,测试类
    • 通俗易懂,直接上图:
      在这里插入图片描述
    • 不是很明白的话,再往下看代码说明

    (2)代码说明

    在这里插入图片描述

    (3)测试

    在这里插入图片描述

    (4)分析优缺点

    • 咋看,没毛病,通俗易懂;再看,不便于维护,屎代码,恶心难受
    • 我知道看完之后肯定觉得这段代码通俗易懂,简单的不能再简单了,而且你还会觉得,即便下次再收养个猫,复制剪贴加上就行了呀,也挺好维护的呀,真的吗?那问题是?请继续……

    2.1.2 反例2——反例1上维护

    (1)类图说明

    在这里插入图片描述

    (2)代码说明

    在这里插入图片描述
    在这里插入图片描述

    (3)测试

    在这里插入图片描述

    (4)分析优缺点

    1)优缺点分析
    • 这样增加新功能的时候看似简单,也确实不难,但是随着项目的扩大,尤其是实际开发的项目非常的庞大,像这样每增加一个新功能,每增加一个新类你都要改养殖场类 FamilyFarm(你可以这么理解,我就是一个养殖场,你有新品种了直接给我送来就行,我为啥还要各种修改呢,我不动不行吗?你不给我提供快捷方式,我不跟你合作了……)
    • FamilyFarm 是一个养殖场,可能养很多动物,具体养什么不知道,你可以把他理解抽象一点儿,而狗狗和小猫的成长过程都是具体的细节,所以 FamilyFarm 不应该依赖细节,否则就像上面代码一样后续维护困难,倒置养殖场不跟你合作了。
    2)如何解决?
    • 怎么解决呢,这就需要我们的依赖倒置原则了:
      FamilyFarm 不是没有依赖抽象吗?那我们就引进抽象,不让他依赖具体细节,那抽象又是怎么,怎么设置呢?
      你想呀,FamilyFarm 不能依赖狗狗猫猫成长过程的那些细节了,所以抽象就是要把狗狗猫猫羊羊🐖🐖的成长细节抽象出来,说到这里明白了吧!
    • 好了,往下看例子,会更形象点,看完,我让你不想明白就难!
    • 写到这里,突然觉得不继续当老师真的浪费了,害,算了算了,清醒点,别自恋了,真的养不活自己和我的麦兜,还是默默地做个码农吧!

    2.3 正例

    2.2.1 正例1

    (1)类图说明

    • 直接上图:
      在这里插入图片描述
    • 图说明了一切,以后再有新增动物,FamilyFarm 还会继续跟你合作,因为你让他省事到只写一次就为一生,太方便了!

    (2)代码说明

    在这里插入图片描述
    在这里插入图片描述

    (3)测试

    在这里插入图片描述

    (4)分析优缺点

    • 对比反例,代码的可读性明显提高,后续维护也好维护了

    2.2.2 正例2——正例1上维护(接口实现)

    • 这个就不细说了,就是新增一个饲养羊的新功能,你感受一下即可

    (1)类图说明

    在这里插入图片描述

    (2)代码说明

    在这里插入图片描述

    • 这就完了,就问你妙不妙,接下来就是测试了!

    (3)测试

    在这里插入图片描述

    2.2.3 正例3(抽象类实现)

    • 这个就不多说的了,其实是一样的思想,就是接口和抽象类的区别了,直接给图了
      在这里插入图片描述
      在这里插入图片描述

    三、总结

    3.1 倒置?为什么叫倒置?

    • 看完上面案例,现在明白了吗?
    • 反例:家庭农场依赖狗狗猫猫的成长过程的细节
    • 正例:狗狗猫猫羊羊都继承了 petGrowthProcess 接口(即:让细节依赖抽象),家庭农场 依赖抽象,不再依赖细节;这不就倒回来了嘛

    3.3 再琢磨一下官方概念

    • 琢磨概念之前先简单说一下Java基础:
      在Java中,抽象指的是接口或者抽象类,而具体的实现类指的是细节。
    • 依赖倒置基于细节应该依赖抽象等设计理念,相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的框架要稳定的多
    • 使用接口或抽象类的目的是指定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现去完成。
    • 即:依赖倒置的思想就是面向接口编程思想

    3.4 作用

    1. 可以降低类间的耦合性。
    2. 可以提高系统的稳定性。
    3. 可以减少并行开发引起的风险。
    4. 可以提高代码的可读性和可维护性。

    3.5 使用原则

    1. 底层模块,尽量都要有抽象类或者接口,或者两者都具备,这样程序的稳定性会更好;
    2. 变量的声明类型尽量是接口或者是抽象类。
    3. 使用继承时尽量遵循里氏替换原则。

    四、附代码

    反例1

    package com.liu.susu.principle.inversion.example1;
    
    /**
     * @FileName FamilyFarm
     * @Description
     * @Author susu
     * @date 2022-02-13
     **/
    public class FamilyFarm {
    
        public void raiseDog(DogGrowthProcess dogGrowthProcess){
            dogGrowthProcess.dogBorn();
            dogGrowthProcess.dogGrowUp();
            dogGrowthProcess.dogBeRaised();
        }
    }
    
    class DogGrowthProcess {
        public void dogBorn(){
            System.out.println("狗狗-->麦兜出生了……");
        }
        public void dogGrowUp(){
            System.out.println("狗狗-->麦兜长大了……");
        }
        public void dogBeRaised(){
            System.out.println("狗狗-->麦兜被饲养员带走了……");
        }
    }
    
    class ClientTest{
        public static void main(String[] args) {
            //狗狗长大了,开始饲养狗狗
            new FamilyFarm().raiseDog(new DogGrowthProcess());
        }
    }
    

    反例2

    package com.liu.susu.principle.inversion.example2;
    
    /**
     * @FileName Breeder
     * @Description
     * @Author susu
     * @date 2022-02-13
     **/
    public class FamilyFarm {
    
        public void raiseDog(DogGrowthProcess dogGrowthProcess){
            dogGrowthProcess.dogBorn();
            dogGrowthProcess.dogGrowUp();
            dogGrowthProcess.dogBeRaised();
        }
    
        public void raiseCat(CatGrowthProcess catGrowthProcess){
            catGrowthProcess.catBorn();
            catGrowthProcess.catGrowUp();
            catGrowthProcess.catBeRaised();
        }
    
    }
    
    class DogGrowthProcess {
        public void dogBorn(){
            System.out.println("狗狗-->麦兜出生了……");
        }
        public void dogGrowUp(){
            System.out.println("狗狗-->麦兜长大了……");
        }
        public void dogBeRaised(){
            System.out.println("狗狗-->麦兜被饲养员带走了……");
        }
    }
    
    class CatGrowthProcess {
        public void catBorn(){
            System.out.println("小猫-->阿苔出生了……");
        }
        public void catGrowUp(){
            System.out.println("小猫-->阿苔长大了……");
        }
        public void catBeRaised(){
            System.out.println("小猫-->阿苔被饲养员带走了……");
        }
    }
    
    class ClientTest{
        public static void main(String[] args) {
            //开始饲养狗狗
            new FamilyFarm().raiseDog(new DogGrowthProcess());
            //开始饲养小猫
            new FamilyFarm().raiseCat(new CatGrowthProcess());
        }
    }
    

    正例1

    package com.liu.susu.principle.inversion.example3;
    
    /**
     * @FileName FamilyFarm
     * @Description 使用 依赖倒置原则 优化后的代码
     * @Author susu
     * @date 2022-02-13
     **/
    public class FamilyFarm {
    
        public void raisePet(petGrowthProcess petGrowthProcess){
            petGrowthProcess.petBorn();
            petGrowthProcess.petGrowUp();
            petGrowthProcess.petBeRaised();
        }
    
    }
    interface petGrowthProcess{
        void petBorn();
        void petGrowUp();
        void petBeRaised();
    }
    class DogGrowthProcess implements petGrowthProcess{
        public void petBorn(){
            System.out.println("狗狗-->麦兜出生了……");
        }
        public void petGrowUp(){
            System.out.println("狗狗-->麦兜长大了……");
        }
        public void petBeRaised(){
            System.out.println("狗狗-->麦兜被饲养员带走了……");
        }
    }
    
    class CatGrowthProcess implements petGrowthProcess{
        public void petBorn(){
            System.out.println("小猫-->阿苔出生了……");
        }
        public void petGrowUp(){
            System.out.println("小猫-->阿苔长大了……");
        }
        public void petBeRaised(){
            System.out.println("小猫-->阿苔被饲养员带走了……");
        }
    }
    
    class ClientTest{
        public static void main(String[] args) {
            FamilyFarm familyFarm = new FamilyFarm();
            //饲养狗狗
            familyFarm.raisePet(new DogGrowthProcess());
            //饲养小猫
            familyFarm.raisePet(new CatGrowthProcess());
        }
    }
    

    正例2

    package com.liu.susu.principle.inversion.example4;
    
    /**
     * @FileName FamilyFarm
     * @Description 使用 依赖倒置原则 优化后的代码
     * @Author susu
     * @date 2022-02-13
     **/
    public class FamilyFarm {
    
        public void raisePet(petGrowthProcess petGrowthProcess){
            petGrowthProcess.petBorn();
            petGrowthProcess.petGrowUp();
            petGrowthProcess.petBeRaised();
        }
    
    }
    
    interface petGrowthProcess{
        void petBorn();
        void petGrowUp();
        void petBeRaised();
    }
    
    class DogGrowthProcess implements petGrowthProcess{
        public void petBorn(){
            System.out.println("狗狗-->麦兜出生了……");
        }
        public void petGrowUp(){
            System.out.println("狗狗-->麦兜长大了……");
        }
        public void petBeRaised(){
            System.out.println("狗狗-->麦兜被饲养员带走了……");
        }
    }
    
    class CatGrowthProcess implements petGrowthProcess{
        public void petBorn(){
            System.out.println("小猫-->阿苔出生了……");
        }
        public void petGrowUp(){
            System.out.println("小猫-->阿苔长大了……");
        }
        public void petBeRaised(){
            System.out.println("小猫-->阿苔被饲养员带走了……");
        }
    }
    
    //新增功能饲养羊
    class sheepGrowthProcess implements petGrowthProcess{
        public void petBorn(){
            System.out.println("小羊-->点点出生了……");
        }
        public void petGrowUp(){
            System.out.println("小羊-->点点长大了……");
        }
        public void petBeRaised(){
            System.out.println("小羊-->点点被饲养员带走了……");
        }
    }
    
    class ClientTest{
        public static void main(String[] args) {
            FamilyFarm familyFarm = new FamilyFarm();
            //饲养狗狗
            familyFarm.raisePet(new DogGrowthProcess());
            //饲养小猫
            familyFarm.raisePet(new CatGrowthProcess());
            //新增功能饲养羊
            familyFarm.raisePet(new sheepGrowthProcess());
        }
    }
    

    正例3

    package com.liu.susu.principle.inversion.example5;
    
    /**
     * @FileName FamilyFarm
     * @Description 使用 依赖倒置原则 优化后的代码
     * @Author susu
     * @date 2022-02-13
     **/
    public class FamilyFarm {
    
        public void raisePet(petGrowthProcess petGrowthProcess){
            petGrowthProcess.petBorn();
            petGrowthProcess.petGrowUp();
            petGrowthProcess.petBeRaised();
        }
    
    }
    
    abstract class petGrowthProcess{
        public abstract void petBorn();
        public abstract void petGrowUp();
        public abstract void petBeRaised();
    }
    
    class DogGrowthProcess extends petGrowthProcess{
        public void petBorn(){
            System.out.println("狗狗-->麦兜出生了……");
        }
        public void petGrowUp(){
            System.out.println("狗狗-->麦兜长大了……");
        }
        public void petBeRaised(){
            System.out.println("狗狗-->麦兜被饲养员带走了……");
        }
    }
    
    class CatGrowthProcess extends petGrowthProcess{
        public void petBorn(){
            System.out.println("小猫-->阿苔出生了……");
        }
        public void petGrowUp(){
            System.out.println("小猫-->阿苔长大了……");
        }
        public void petBeRaised(){
            System.out.println("小猫-->阿苔被饲养员带走了……");
        }
    }
    
    //新增功能饲养羊
    class sheepGrowthProcess extends petGrowthProcess{
        public void petBorn(){
            System.out.println("小羊-->点点出生了……");
        }
        public void petGrowUp(){
            System.out.println("小羊-->点点长大了……");
        }
        public void petBeRaised(){
            System.out.println("小羊-->点点被饲养员带走了……");
        }
    }
    
    class ClientTest{
        public static void main(String[] args) {
            FamilyFarm familyFarm = new FamilyFarm();
            //饲养狗狗
            familyFarm.raisePet(new DogGrowthProcess());
            //饲养小猫
            familyFarm.raisePet(new CatGrowthProcess());
            //新增功能饲养羊
            familyFarm.raisePet(new sheepGrowthProcess());
        }
    }
    
    展开全文
  • 依赖倒置原则是非常重要的设计原则,几乎贯穿于所有的设计模式。本篇文章通过讨论司机驾驶汽车的场景,分析了使用和不使用DIP原则之间的区别,找出了问题所在(即如何让高层模块是相对稳定的,从而改善系统的可维护性...


    学习具体的设计原则之前,首先要搞清楚为什么要学习设计原则,使用这些原则对项目带来好处。

    🏠 前言:面向对象设计原则

    上一篇中提到,变化是面向对象设计中最大的挑战。如果我们设计的模块符合这些设计原则,它就能够抵御这种变化,将变化带来的影响降到最低。

    1️⃣ 认识面向对象

    为什么是面向对象而不是面向过程呢?如何从抽象层面认识面向对象?

    • 面向对象能够隔离变化
      面向对象的构建方式更能够适应软件的变化,将变化带来的影响降到最小
    • 面向对象强调各司其职,各负其责
      面向对象的方式强调各个类的责任,由于需求变化导致的新增类型不应该影响原有类型的实现,每个类各负其责。实际上,各负其责实现的背后是面向对象的多态机制,即通过统一的接口,能够调用不同的实现方式。
    • 对象是什么
      对象封装了接口和数据,提供了一系列可以使用的公共接口,是拥有某种责任的抽象。

    2️⃣为什么先学习原则

    接下来开始学习八大设计原则,这些设计原则比具体的设计模式更重要,为什么?
    因为理解了这八大设计原则,你有可能发明属于自己的设计模式,也能够更容易地看懂其他领域的设计模式。所有的设计模式都是依赖这些原则推导出来的。简单的说,后面要学习的设计模式是这些设计原则在某种特定场景下的具体表现。在学习具体的设计模式时,可以拿这些设计原则衡量其品质,检查该模式有没有违背设计原则。

    ⭐依赖倒置原则

    1️⃣标准定义

    依赖倒置原则(DIP, Dependency Inversion Principle)标准定义如下:

    High level modules should not depend upon low level modules. Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions.

    高层模块(稳定)不应该依赖于低层模块(变化); 二者都应该依赖于抽象(稳定);
    抽象(稳定)不应该依赖于实现细节(变化),实现细节(变化)应该依赖于抽象(稳定)。

    2️⃣如何理解

    **如何理解这三句话呢?**不妨举一个简单的例子(以《设计模式之禅》中的司机驾驶汽车场景为例):
    现在有一个司机驾驶奔驰汽车的场景。
    在这里插入图片描述

    奔驰汽车提供了run方法,代表车辆的运行; 司机通过调用奔驰车的run方法开动奔驰。client1函数是具体的业务逻辑,描述了司机驾驶奔驰车的场景, 下面是具体实现代码(c++)。
    在这里插入图片描述
    以上的代码,确实能够完成司机驾驶奔驰车的业务场景。但是现在业务需求变更了,司机不仅要开奔驰,还要开宝马,按照上面的实现方式,该如何修改呢?
    [1] 首先需要新增宝马车类型
    在这里插入图片描述
    [2] 其次还需要让司机支持开宝马车的接口
    在这里插入图片描述
    此时细心的你已经发现了,为了让司机能够驾驶宝马,不仅需要增加宝马,还要让司机增加新的接口,并且也需要修改业务逻辑代码。这里仅仅增加了一个车类型,就需要修改司机类,后果就是系统的可维护性和可读性大大降低。这里汽车是不稳定的,会有不同的汽车类型出现; 而司机又依赖于不稳定的低层模块汽车,因此司机也是不稳定的,需要频繁地增加针对不同车类型的接口,才能满足变化的业务需求。

    ☃️那如何让司机是相对稳定的,即不管汽车如何变化,司机都不需要调整呢?
    根据依赖倒置原则,我们给不稳定的汽车和司机之间引入一个抽象车类型ICar。汽车类型不管怎么变化,最终是用来驾驶的,因此可以把run方法提取出来,代表汽车的运行,当做抽象层接口。ICar是稳定的,而司机只需依赖稳定的接口ICar,不同类型的车也只需依赖稳定的接口ICar,这样ICar接口就隔离了变化,使得高层模块司机类是相对稳定的。
    在这里插入图片描述
    这里的ICar是抽象接口,提供了抽象车类型必须要有的run功能,不需要实现,因此定义成纯虚函数。run接口必须是虚函数,因为司机类的drive方法内部会调用抽象层ICar的run接口,此时通过编程语言的多态机制,car.run()会自动调用派生自ICar接口的具体实现类的run方法。
    在这里插入图片描述
    回过头来再分析,高层模块(稳定)不应该依赖于低层模块(变化),二者都应该依赖于抽象(稳定);这里的高层模块便是司机类,低层模块是变化的具体车类型,我们引入了稳定的抽象接口ICar,让高层模块司机类和低层模块具体车类型都依赖于抽象接口;司机类操作抽象接口ICar,屏蔽了具体类型的车的实现细节,因此司机类是相对稳定的。抽象(稳定)不应该依赖于实现细节(变化),实现细节(变化)应该依赖于抽象(稳定);ICar不依赖具体的车类型实现,而具体类型的车依赖于抽象接口ICar。

    司机需要开宝马车,只需要增加低层模块宝马车和调整业务场景即可,不再需要修改高层模块司机类,这样就把业务需求变化带来的影响降到了最低。

    3️⃣本质

    依赖倒置原则本质就是通过抽象的接口和类,使得各个类或模块的实现彼此独立,实现了模块之间的松耦合。

    4️⃣优点

    依赖导致原则有哪些优点呢?
    [1] 通过抽象接口使各模块的实现彼此独立,不会互相影响,实现了模块间的松耦合(DIP原则的本质)
    [2] 规避一些非技术因素引起的问题(项目越大,需求变化的概率也越大,通过DIP原则设计的接口对实现类进行约束,可以减少需求变化引起的工作量剧增问题。同时,人员发生变动时,只要文档完善,也可让维护人员轻松地扩展和维护)
    [3] 促进并行开发(两个类之间有依赖关系,只需制定出两者之间的接口就能独立开发,规范定好了,而且项目间的单元测试也能独立进行)


    5️⃣如何理解"倒置"

    如何理解依赖倒置原则中的"倒置"呢?
    下面是维基百科对依赖倒置原则的定义(https://zh.wikipedia.org/zh-hans/依赖反转原则):

    在面向对象编程领域中,依赖反转原则(Dependency inversion principle,DIP)是指一种特定的解耦(传统的依赖关系建立在高层次上,而具体的策略设置则应用在低层次的模块上)形式,使得高层次的模块不依赖于低层次的模块的实现细节,依赖关系被颠倒(反转),从而使得低层次模块依赖于高层次模块的需求抽象。该原则规定:
    [1] 高层次的模块不应该依赖于低层次的模块,两者都应该依赖于抽象接口。
    [2] 抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。

    一个复杂的系统必然存在高层与低层,并且,高层使用低层提供的“服务”来实现自己的业务逻辑,即所谓的高层依赖低层。但如果高层直接使用这些低层对象,当业务变化导致低层已有的功能无法满足高层的服务需求时,就需要“伤筋动骨”。为了避免这样的问题,人们提出了面向接口编程,即只要接口不发生变化,低层的实现不会影响高层的使用。
    按照常理,通常将相同语义的元素放在一起,因此接口与其实现(类)应该处于同一层模块之中(如下面左侧图所示)。这看似好像没问题,但是软件的高层应用因为客户需求的变更会而发生变化。当高层应用变化时,那它依赖的低层提供的服务也很可能需要发生变化。那么问题来了,🤔谁来约定这个接口提供什么样的服务呢?按照前面的逻辑,接口和实现放在低层,那接口约束应该由低层提供,可是低层开发人员并不负责高层的应用逻辑。低层应该应该只负责响应高层的需求,按照需求提供实现服务。但现在接口放在低层维护,就应该由低层开发人员负责体现需求接口的“变更”(提供新的服务)。此时会发现,高层应用的开发人员拥有需求,但无法约束定义描述需求的接口;负责低层的开发人员则不管需求,只应该提供具体实现,却在维护跟应用需求有关的接口。这不就出现了矛盾吗?为了解决这种矛盾,人们提出将本应放在低层的接口放在高层,低层的实现依赖高层提供的接口,去实现相应的服务(下面右侧图所示),这才是DIP中“倒置”的真正含义。

    在这里插入图片描述


    6️⃣如何使用它

    那么实际工作或学习中,如何有效地使用依赖倒置原则
    [1] 首先分析出有哪些高层模块和低层模块,注意高层模块是依赖于低层模块的;
    [2] 接着分析低层模块的稳定性,如果低层模块一直是稳定的,未来也不会发生任何变化,那没有必要采用DIP原则;如果低层模块是变化的,未来可能会被新的低层模块替代,此时就需要引入抽象接口,让高层模块和低层模块都依赖于抽象层;
    [3] 接口负责定义public属性和方法,并且声明和高层模块和低层模块之间的依赖关系;抽象类负责实现所有低层模块都必须具备的公共部分;实现类负责实现业务逻辑,对抽象接口进行扩展与细化。
    [4] 子类尽量不要覆写抽象类中已经实现的方法,因为高层模块依赖于抽象类中已经实现的这个方法,而子类如果覆写了,可能对高层模块的稳定性产生一定的影响。

    🎈总结时刻

    依赖倒置原则是非常重要的设计原则,几乎贯穿于所有的设计模式。本篇文章通过讨论司机驾驶汽车的场景,分析了使用和不使用DIP原则之间的区别,找出了问题所在(即如何让高层模块是相对稳定的,从而改善系统的可维护性和可读性);接着根据DIP原则的三句话定义,实现了相对稳定的,可维护性和可读性较好的版本,最后在对比中得出了依赖导致原则的本质和优点。

    🍁记住一句话

    如果这篇文章内容你只能记住一件事,那请记住:面向接口编程,让高层和低层模块都依赖于抽象接口,使得抽象接口把低层模块的变化隔离起来,从而实现高层模块的相对稳定


    参考资料
    [1] 《设计模式:可复用面向对象软件的基础》
    [2] 《设计模式之禅》
    [3] 《依赖反转(依赖倒置)原则之“反转(倒置)”》(https://www.jianshu.com/p/8d7723cd4e24)

    展开全文
  • 什么叫依赖倒置

    千次阅读 2022-03-06 10:33:20
    文章目录正向依赖双向依赖依赖倒置 在一个复杂的软件架构里,为了方便软件的开发和维护,会把软件划分为多个模块,并进行分层。 如下图所示,理想情况下: (1)模块B调用操作系统的接口,实现自己的功能,并提供API给...


    在一个复杂的软件架构里,为了方便软件的开发和维护,会把软件划分为多个 模块,并进行 分层

    如下图所示,理想情况下:
    (1)模块B调用操作系统的接口,实现自己的功能,并提供API给模块A;
    (2)模块A调用模块B的API,实现自己的功能,并提供API给用户界面;
    (3)用户界面调用模块A的API,实现自己的功能,并提供API给客户;
    在这里插入图片描述
    上面所说的“调用”是一种依赖关系。A需要调用B提供API才能完成自己的功能,称为A依赖B

    上层软件和下层软件是相互的,比如AB的上层,A用户界面的下层。

    正向依赖

    正向依赖指上层模块依赖下层模块,只是最普遍的依赖关系。

    用户界面依赖AB和操作系统。
    A依赖B和操作系统。
    B依赖操作系统。
    在这里插入图片描述

    双向依赖

    在某些情况下,下层模块也要依赖上层模块,形成了双向依赖。

    如图所示,在A依赖B的同时,B也依赖了A
    在这里插入图片描述
    双向依赖会引发一系列问题,如编译bug、维护性降低。

    出现双向依赖意味着软件的设计有问题,需要对相关模块进行更细致的分层,或使用依赖倒置解决。

    依赖倒置

    依赖倒置提供了一种下层依赖上层手段。

    如下图所示,当B需要调用到A的接口时,不直接调用它(会产生双向依赖),而是调用B自己定义的一个虚接口,在运行时由A提供这个虚接口的实现

    C语言中,使用函数指针表示这个虚接口,运行时把B依赖的A的接口赋值给这个函数指针,B通过函数指针间接调用A的接口。

    C++语言中,除了函数指针,还可以使用面向对象语言专有的虚函数,由A实现或重写B定义的虚函数。
    在这里插入图片描述
    所谓“倒置”是指:上层模块从依赖方变成了被依赖方;下层模块从被依赖方变成了依赖方。就是反向依赖的意思。

    展开全文
  • 将一句话的单词进行倒置,标点不倒置。比如 I like beijing. 经过函数后变为:beijing. like I 输入描述: 每个测试输入包含1个测试用例: I like beijing. 输入用例长度不超过100 输出描述: 依次输出倒置之后...
  • 依赖倒置原则(DIP) 定义: 高层模块不应该依赖于底层模块,两者都应该依赖其抽象。抽象不应该依赖细节,细节应该依赖于抽象。是实现开闭原则的基础,其实就是面向接口编程的解释,也就理解了依赖倒置。 详细描述...
  • Java设计模式-七大架构设计原则-依赖倒置原则
  • JAVA倒置字符串

    2021-11-29 22:09:12
    Java倒置字符串 示例: 输入:I like beijing. 输出:beijing. like I
  • ioc 依赖倒置 今天,我们将讨论所有主题中最令人困惑的主题之一,看看我们能否解开依赖倒置,控制倒置和依赖注入的混乱局面。 理解每个名称的细节并不完全重要,因为许多人最终会互换使用它们。 我们不太可能要纠正...
  • 依赖倒置原则有三层意思: 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的 接口或抽象类不依赖于实现类 实现类依赖于接口或抽象类 二、案例解析 ...
  • 【设计原则】依赖倒置原则 (面向接口编程)

    多人点赞 热门讨论 2022-02-08 17:27:13
    下面先讲一讲依赖倒置原则,再过渡到案例解释。 本文目的在于用极其简单的图解帮助新手来简单的理解面向接口开发,并不会提出很高深的理论支持来描述。 文章若有错误的内容,希望大佬指正 依赖倒置原则 什么是依赖...
  • 今天学习c的时候遇到了一道题,要求将一个字符串里面的单词倒置,标点不倒置。例如,输入i like beijing.要将这个字符串输入为beijing. like i这个形式。我自己写了一种比较常规也算是比较笨的方式,然后看了下别人...
  • 依赖倒置是面向对象设计领域的一种软件设计原则。 有人会有疑惑,设计原则有什么用呢?设计原则是前辈们总结出来的经验,你可以把它们看作是内功心法。只要你在平常开发中按照设计原则进行编码,假以时日,你编程的...
  • 依赖倒置原则(Dependence Inversion Principle):面向接口编程 1、定义:    正置:实现类之间的相互依赖;    倒置:抽象(接口或者抽象类)之间的依赖;    依赖倒置原则的定义有以下三点:    1)高层模块...
  • 1.在Java中如何将数组中的数据倒置1)如果要自己实现这个reverse方法,最直观的方式就是新建一个数组,将原数组从最后往前一个个放进新的数组中,代码如下:public class Test {public static void main(String[] ...
  • 依赖倒置原则定义 如下(可先不管) - 高层模块不应该依赖低层模块,两者都应该依赖抽象 - 抽象不应该依赖细节 - 细节应该依赖抽象 情景描述 当前有一家饮料店,里面卖着很多饮料 设计如下 问题...
  • 这篇文章介绍的内容是关于PHP:依赖注入,控制反转,依赖倒置原则 ,有着一定的参考价值,现在分享给大家,有需要的朋友可以参考一下判断代码的好坏,我们有自己的标准:高内聚,低耦合。为了解决这一问题,php中有...
  • 依赖倒置原则

    2019-10-28 11:18:04
    依赖倒置原则定义 依赖倒置原则(Dependence Inversion Principle ,DIP)定义如下: High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions ...
  • 前言:为什么要用整篇文章来写好像跟领域模型干系不大的《依赖倒置》呢?因为《依赖倒置》是六边形架构的核心!毫不夸张的说,不理解《依赖倒置》的程序员只能写功能,没法写出框架来!不论是依赖注入di或者依赖倒置...
  • SOLID设计原则--依赖倒置原则背景SOLID设计原则依赖倒置原则(DIP)什么是依赖倒置原则定义解释说明依赖倒置原则的使用需求描述解决方案一优缺点分析解决方案二谁和谁的依赖被倒置了?总结 背景 设计原则–>设计...
  • 通过这篇文章,你将了解到控制反转(IoC)是什么?「反转」到底反转了什么? Spring和IOC之间是什么关系? 依赖注入(DI)和依赖倒置原则(DIP)又是什么?IOC、DI和DIP有什么关系?
  • C语言之实现倒置字符串的两种方法

    多人点赞 2022-08-08 21:04:23
    C语言之倒置字符串
  • 所以我们要自己创建函数来求字符串的元素个数 求出的字符串长度-1是最后一个元素的下标,因为第一个元素的参数为0,所以最后一个参数的元素=字符串长度-1 我们创建while(left 但我们的my_string函数还没有创建,我...
  • 输入非负整数N(0≤N≤2147483647),将各位数字倒置后输出 输入200003 输出300002 自己写的少最后以为,求大神指点
  • 在面向对象编程领域中,依赖倒置原则(Dependency inversion principle,DIP)是指一种特定的解耦(传统的依赖关系创建在高层次上,而具体的策略设置则应用在低层次的模块上)形式,使得高层次的模块不依赖于低层次...
  • c++依赖倒置原则

    千次阅读 2017-10-17 13:19:42
    C++依赖倒置原则
  • 煮大米,加热10分钟就好 大米客户可以自己准备,时间客户也能够跳转,上线后程序运行得非常愉快,从未出现过bug,老板也夸奖了该小白开发,但是有一天,来了一个需求:老板说,要求该高压锅还能炒菜,还需要支持炖...
  • 软件设计——依赖倒置目录博主介绍前言到底什么是依赖注入(DI)和控制反转(IoC)?Java Spring中的DI和IoC如何在JavaScript中使用IoC?依赖注入的问题和局限性结尾????点击直接资料领取???? 目录 博主介绍 ???? 个人...
  • 依赖倒置原则讲解

    2019-05-28 17:34:46
    现在我们来学习依赖倒置原则,首先我们来看一下他的定义,高层模块不应该依赖底层模块,两者都应该依赖其抽象, 抽象不应该依赖细节,细节应该依赖于抽象,针对接口编程,而不要针对实现编程,那我们使用抽象包括引用接口, ...
  • 依赖倒置和控制反转

    2020-04-21 12:47:44
    依赖倒置 定义 依赖反转原则(Dependency inversion principle,DIP)是指一种特定的解耦形式,使得高层次的类不依赖于低层次的类的实现细节,依赖关系被颠倒(反转),从而使得低层次类依赖于高层次类的需求抽象。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,337
精华内容 14,134
关键字:

倒置自己