精华内容
下载资源
问答
  • 主要介绍了深入理解JavaScript系列(22):S.O.L.I.D五大原则之依赖倒置原则DIP详解,本文讲解了DIP and JavaScript、何时依赖注入等内容,需要的朋友可以参考下
  • 依赖倒置原则Demo

    2015-11-29 11:18:09
    http://blog.csdn.net/xingjiarong/article/details/50094307
  • 依赖倒置原则

    2019-01-01 20:34:19
    设计模式六大原则之三:依赖倒置原则

    前方高能《一故事一设计模式》PDF 电子书已经上线,关注公众号即可获取。

    个人博客原文:
    依赖倒置原则

    雪

    设计模式六大原则之三:依赖倒置原则。

    简介

    姓名 :依赖倒置原则

    英文名 :Dependence Inversion Principle

    价值观 :大男子主义的典型代表,什么都得通过老大或者老爸同意

    伴侣 :一定是个温柔体贴的女子

    个人介绍

    1. High level modules should not depend upon low level modules.Both should depend upon abstractions. 高层模块不应该依赖低层模块,两者都应该依赖其抽象(模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的)
    2. Abstractions should not depend upon details. 抽象不应该依赖细节(接口或抽象类不依赖于实现类)
    3. Details should depend upon abstractions. 细节应该依赖抽象(实现类依赖接口或抽象类)

    给大家讲个故事,我胡乱想的,如有雷同,肯定是英雄所见略同。那必须交个朋友。

    一个小村里,有两家饭馆,虽然挂着不同的牌子,挨在一起,但是老板确是表兄弟。这两兄弟抠得很,为了节省成本,密谋了一个想法:在两家饭馆谁家忙的时候,可以让不忙的那家的员工过去支援一下。这样子,本来每家饭馆都需要 2 个洗碗工,总共需要 4 个,他们就只招了 3 个,省了 1 个洗碗工的成本,当然不止洗碗工,还有服务员等等。两兄弟约定了规则:

    1. A 饭馆需要支援的时候,B 饭馆老板,让 B 饭馆老板选哪个员工去支援,不能直接让 A 饭馆的员工直接找 B 饭馆的员工去帮忙,但可以让 A 饭馆员工找 B饭馆老板告知需要支援。
    2. 虽然老板权利大,但是也不能说 A 饭馆老板直接叫 B 饭馆的员工去帮忙。
    3. 员工没有真实的老板,今天为 A 饭馆工作就是 A 饭馆的员工,没有跟定哪个老板。

    大概通过这个小故事,描述了依赖倒置原则的基本内容。

    代码复原

    下面通过代码来模拟这个故事。

    错误的示范

    这个错误的示范将就看哈,可能有些问题没描述清楚。

    老板和员工抽象

    abstract class Boss {
    
        abstract void support();
    
        abstract void askHelp(Boss boss);
    }
    
    abstract class Staff {
    
        private String name;
    
        abstract void service();
    
        abstract void askHelp(Boss boss);
    
        public String getName() {
            return name;
        }
    
        public void setName(String name) {
            this.name = name;
        }
    }
    

    老板具体类

    class BossA extends Boss {
    
        private StaffA staffA;
    
        public BossA(StaffA staffA) {
            this.staffA = staffA;
        }
    
        @Override
        void support() {
            staffA.service();
        }
    
        @Override
        void askHelp(Boss boss) {
            boss.support();
        }
    
    }
    
    class BossB extends Boss {
    
        private StaffB staffB;
    
        public BossB(StaffB staffB) {
            this.staffB = staffB;
        }
    
        @Override
        void support() {
            staffB.service();
        }
    
        @Override
        void askHelp(Boss boss) {
            boss.support();
        }
    }
    

    员工具体类

    class StaffA extends Staff {
    
        public StaffA(String name) {
            this.setName(name);
        }
    
        @Override
        void service() {
            System.out.println(this.getName() + "提供服务");
        }
    
        @Override
        void askHelp(Boss boss) {
            boss.support();
        }
    }
    
    class StaffB extends Staff {
    
        public StaffB(String name) {
            this.setName(name);
        }
    
        @Override
        void service() {
            System.out.println(this.getName() + "提供服务");
        }
    
        @Override
        void askHelp(Boss boss) {
            boss.support();
        }
    }
    

    测试代码

    /** 初始化老板和员工 */
    StaffA staffA = new StaffA("A 员工");
    StaffB staffB = new StaffB(" B 员工");
    Boss bossA = new BossA(staffA);
    Boss bossB = new BossB(staffB);
    
    /** A 老板向 B 老板求支援 */
    bossA.askHelp(bossB); // 打印出:B 员工提供服务
    
    /** B 员工向 A 老板求支援 */
    staffB.askHelp(bossA); // 打印出:A 员工提供服务
    

    好像看起来实现了要求了,但是其实这段代码没有按照上面的 3 点规则编写,破坏了第 3 点规则,老板们的员工没有用员工的抽象类,破坏了细节依赖抽象这一点。设想一下,假如现在 A 老板把 A 员工辞退了,重新招了个 C 员工,那么怎么实现呢?是不是需要再新增一个 StaffC 类,然后再修改 BossA 类代码,把 StaffA 换成 StaffC。这样超级麻烦,在平时写项目中要时刻考虑这一点:在具体实现类使用其他类,是不是可以用其抽象类?

    代码:

    DIPErrorTest.java

    正确的示范

    看了上面那个憋屈的代码,再来看下面简洁的代码,才会发现依赖倒置原则是多么强大。

    老板和员工抽象类

    abstract class Boss2 {
    
        private Staff2 staff;
    
        public Boss2(Staff2 staff) {
            this.staff = staff;
        }
    
        abstract void support();
    
        abstract void askHelp(Boss2 boss);
    
        public void setStaff(Staff2 staff) {
            this.staff = staff;
        }
    
        public Staff2 getStaff() {
            return staff;
        }
    }
    
    abstract class Staff2 {
    
        private String name;
    
        abstract void service();
    
        abstract void askHelp(Boss2 boss);
    
        public void setName(String name) {
            this.name = name;
        }
    
        public String getName() {
            return name;
        }
    }
    

    老板类

    class BossImpl extends Boss2 {
    
        public BossImpl(Staff2 staff) {
            super(staff);
        }
    
        @Override
        void support() {
            this.getStaff().service();
        }
    
        @Override
        void askHelp(Boss2 boss) {
            boss.support();
        }
    }
    

    员工类

    class StaffImpl extends Staff2{
    
        public StaffImpl(String name) {
            this.setName(name);
        }
    
        @Override
        void service() {
            System.out.println(this.getName() + "提供服务");
        }
    
        @Override
        void askHelp(Boss2 boss) {
            boss.support();
        }
    }
    

    测试类

    /** 正确示范 */
    Staff2 staffA2 = new StaffImpl("A 员工");
    Staff2 staffB2 = new StaffImpl("B 员工");
    Boss2 bossA2 = new BossImpl(staffA2);
    Boss2 bossB2 = new BossImpl(staffB2);
    
    /** A 老板向 B 老板求支援 */
    bossA2.askHelp(bossB2); // 打印出:B 员工提供服务
    
    /** B 员工向 A 老板求支援 */
    staffB2.askHelp(bossA2); // 打印出:A 员工提供服务
    
    /** A 老板辞退了 A 员工,换成了 C 员工 */
    Staff2 staffC2 = new StaffImpl("C 员工");
    bossA2.setStaff(staffC2);
    
    /** B 员工向 A 老板求支援 */
    staffB2.askHelp(bossA2); // 打印出:C 员工提供服务
    
    

    这代码相比上面错误的示范,简洁了很多,实现的功能却更灵活,这就是依赖倒置原则强大的地方,它可以将类的耦合性降低,提供灵活的处理。

    代码:

    DIPRightTest.java

    最佳实践

    1. 变量的表面类型尽量是接口或者是抽象类
    2. 任何类都不应该从具体类派生
    3. 尽量不要覆写基类的方法
    4. 结合里氏替换原则使用
      (来自《设计模式之禅》)

    总结

    总的来说,要实现依赖倒置原则,要有『面向接口编程』这个思维,掌握好这个思维后,就可以很好的运用依赖倒置原则。

    参考资料:《大话设计模式》、《Java设计模式》、《设计模式之禅》、《研磨设计模式》、《Head First 设计模式》

    希望文章对您有所帮助,设计模式系列会持续更新,感兴趣的同学可以关注公众号,第一时间获取文章推送阅读,也可以一起交流,交个朋友。

    公众号之设计模式系列文章

    公众号

    展开全文
  • 一、什么是依赖倒置原则 Dependence Inversion Principle,简称DIP,是指高层模块(直接调用层)不应该依赖底层模块(具体的实现层),反过来也是,它们之间应该依赖抽象层。 也就是说在高层模块与底层模块之间,...

    一、什么是依赖倒置原则

    Dependence Inversion Principle,简称DIP,是指高层模块(直接调用层)不应该依赖底层模块(具体的实现层),反过来也是,它们之间应该依赖抽象层。

    也就是说在高层模块与底层模块之间,使用抽象层做桥梁,高层模块只管使用抽象层的东西,底层模块只管基于抽象层拓展各种个性功能,高层模块依赖抽象,底层模块依赖抽象,在运行态中传入不同的实例即可无缝地完成各种需求(借助了里氏替换原则),同时也是开闭原则的基础。

    在java中具体点就是,在一个调用类(高层模块)中只调用接口/抽象类(抽象层)的方法,而使用各种不同的具体类(底层模块)去实现这个接口/抽象类的方法,在使用的时候直接传入这些具体类的实例可以达到调用不同的方法。

    二、依赖倒置的优点

    • 强调面向接口编程,降低类与类之间的耦合性

    使用接口或抽象类去定义规范和契约,不涉及具体操作,调用类直接遵循这些规范或契约来使用,不必担心具体是如何操作的;而实现类只管根据这些规范和契约去实现不同的功能,最终通过里氏替换,达到最终目的,相互独立、解耦,除非变动规范和契约

    • 增强系统的稳定性

    具体细节变化多端,而抽象想多稳定,以抽象为基础、面向接口编程的系统比面向细节的稳定多了。

    • 提高代码的可读性和维护性

    依赖关系清晰明了,高层与底层相互解耦,各自维护也相互不影响

    • 降低修改代码带来的风险

    因为相互解耦,有一块功能代码出现bug,修改这一块代码不会影响其他块的正常使用。

    三、依赖倒置的缺点

    除了抽象难度大点以外,几乎无缺点,依赖倒置还是挺基础、使用的一个原则。

    四、依赖倒置的具体实现

    1.  定义一个接口(作为高层与底层的依赖桥梁)

    public interface IBridge {
        void connect();
    }

    2. 定义一个调用类(高层模块,只依赖接口)

    public class dock {
        public static void joint(IBridge bridge){
            bridge.connect();
        }
    }

    3. 定义多个接口的具体类(底层模块,只实现接口)

    public class BridgeA implements IBridge {
        @Override
        public void connect() {
            System.out.println("连接船A");
        }
    }
    
    public class BridgeB implements IBridge {
        @Override
        public void connect() {
            System.out.println("连接船B");
        }
    }

    4. 测试类(只需要传入接口的实例即可完成调用)

    public class Test {
        public static void main(String[] args) {
            Dock.joint(new BridgeA());
            Dock.joint(new BridgeB());
        }
    }

    展开全文
  • 开闭原则 依赖倒置原则 到目前为止,我们只研究了单一职责 , 打开/关闭 , liskov替换和接口隔离原则。 依赖倒置是我们所要研究的最后一个原理之一。 该原则指出 答:高级模块不应依赖于低级模块。 两者都应依赖...

    开闭原则 依赖倒置原则

    到目前为止,我们只研究了单一职责打开/关闭liskov替换接口隔离原则。
    依赖倒置是我们所要研究的最后一个原理之一。
    该原则指出

    答:高级模块不应依赖于低级模块。 两者都应依赖抽象。
    B.抽象不应依赖细节。 细节应取决于抽象。

    让我们开始一些违反该原理的代码。
    作为软件团队,我们需要实施一个项目。 目前,软件团队包括:

    后端开发人员

    package com.gkatzioura.solid.di;
    
    public class BackEndDeveloper {
    
        public void writeJava() {
        }
    }

    还有一个FrontEnd开发人员

    package com.gkatzioura.solid.di;
    
    public class FrontEndDeveloper {
    
        public void writeJavascript() {
        }
    
    }

    我们的项目在整个开发过程中都使用。

    package com.gkatzioura.solid.di;
    
    public class Project {
    
        private BackEndDeveloper backEndDeveloper = new BackEndDeveloper();
        private FrontEndDeveloper frontEndDeveloper = new FrontEndDeveloper();
    
        public void implement() {
    
            backEndDeveloper.writeJava();
            frontEndDeveloper.writeJavascript();
        }
    
    }

    因此,我们可以看到Project类是一个高级模块,它依赖于诸如BackEndDeveloper和FrontEndDeveloper之类的低级模块。 实际上,我们违反了依赖倒置原则的第一部分。

    同样通过检查Project.class的实现功能,我们认识到方法writeJava和writeJavascript是绑定到相应类的方法。 关于项目范围,这些都是细节,因为在两种情况下它们都是开发形式。 因此,违反了依赖倒置原则的第二部分。

    为了解决这个问题,我们将实现一个称为Developer接口的接口。

    package com.gkatzioura.solid.di;
    
    public interface Developer {
    
        void develop();
    }

    因此,我们引入一个抽象。

    BackEndDeveloper应该重构为

    package com.gkatzioura.solid.di;
    
    public class BackEndDeveloper implements Developer {
    
        @Override 
        public void develop() {
            writeJava();
        }
        
        private void writeJava() {
        }
        
    }

    并且将FrontEndDeveloper重构为

    package com.gkatzioura.solid.di;
    
    public class FrontEndDeveloper implements Developer {
    
        @Override 
        public void develop() {
            writeJavascript();
        }
        
        public void writeJavascript() {
        }
        
    }
    [/sourecode]
    
    The next step in order to tackle the violation of the first part would be to refactor the Project class so that it will not depend on the FrontEndDeveloper and the BackendDeveloper class.
    
    
    package com.gkatzioura.solid.di;
    
    import java.util.List;
    
    public class Project {
    
        private List<Developer> developers;
        
        public Project(List<Developer> developers) {
        
            this.developers = developers;
        }
    
        public void implement() {
    
            developers.forEach(d->d.develop());
        }
    
    }

    结果是Project类不依赖于较低级别的模块,而是依赖于抽象。 低层模块及其细节也取决于抽象。

    您可以在github上找到源代码。

    另外,我还编写了备忘单,其中包含有关扎实原则的摘要。 在链接中注册以接收它。

    翻译自: https://www.javacodegeeks.com/2018/02/solid-principles-dependency-inversion-principle.html

    开闭原则 依赖倒置原则

    展开全文
  • 在软件开发中,为了提高软件系统的可...依赖倒置原则告诉我们要面向接口编程;单一职责原则告诉我们实现类要职责单一;接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合度;合成复用原

    在软件开发中,为了提高软件系统的可维护性和可复用性,增加软件的可扩展性和灵活性,程序员要尽量根据 7 条原则来开发程序,从而提高软件开发效率、节约软件开发成本和维护成本。

    这 7 种设计原则是软件设计模式必须尽量遵循的原则,各种原则要求的侧重点不同。其中,开闭原则是总纲,它告诉我们要对扩展开放,对修改关闭;里氏替换原则告诉我们不要破坏继承体系;依赖倒置原则告诉我们要面向接口编程;单一职责原则告诉我们实现类要职责单一;接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合度;合成复用原则告诉我们要优先使用组合或者聚合关系复用,少用继承关系复用。

     

    1、开闭原则

    原则定义:

    软件实体应当对扩展开放,对修改关闭,这就是开闭原则的经典定义。
    
    这里的软件实体包括以下几个部分:
    1.项目中划分出的模块
    2.类与接口
    3.方法
    
    开闭原则的含义是:当应用的需求改变时,在不修改软件实体的源代码或者二进制代码的前提下,可以扩展模块的功能,使其满足新的需求。

    实现原理:

    可以通过“抽象约束、封装变化”来实现开闭原则,即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层,而将相同的可变因素封装在相同的具体实现类中。
    
    因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展,当软件需要发生变化时,只需要根据需求重新派生一个实现类来扩展就可以了。

    实例展示:

    /**
     * 定义课程接口
     */
    public interface ICourse {
        String getName();  // 获取课程名称
        Double getPrice(); // 获取课程价格
        Integer getType(); // 获取课程类型
    }
    
    /**
     * 英语课程接口实现
     */
    public class EnglishCourse implements ICourse {
    
        private String name;
        private Double price;
        private Integer type;
    
        //省略get,set,空参,满参
    }
    
    // 测试
    public class Main {
        public static void main(String[] args) {
            ICourse course = new EnglishCourse("小学英语", 199D, "Mr.Zhang");
            System.out.println(
                    "课程名字:"+course.getName() + " " +
                    "课程价格:"+course.getPrice() + " " +
                    "课程作者:"+course.getAuthor()
            );
        }
    }

    项目上线,但是出现了节假日打折的情况出现,现在有以下这几种方法去修改:

    1:修改接口(不可取,修改接口时其他的代码也得改!)

    2:修改实现类(不可取,这样会有两个获取价格的方法!)

    3:扩展实现方法(可取,不改变原有代码,功能可实现!)

    直接添加一个子类 SaleEnglishCourse ,重写 getPrice()方法,这个方案对源代码没有影响,符合开闭原则,所以是可执行的方案

    public class SaleEnglishCourse extends EnglishCourse {
    
        public SaleEnglishCourse(String name, Double price, String author) {
            super(name, price, author);
        }
    
        @Override
        public Double getPrice() {
            return super.getPrice() * 0.85;
        }
    }

    开闭原则的作用

    开闭原则是面向对象程序设计的终极目标,它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说,其作用如下。
    
    1. 对软件测试的影响
    软件遵守开闭原则的话,软件测试时只需要对扩展的代码进行测试就可以了,因为原有的测试代码仍然能够正常运行。
    2. 可以提高代码的可复用性
    粒度越小,被复用的可能性就越大;在面向对象的程序设计中,根据原子和抽象编程可以提高代码的可复用性。
    3. 可以提高软件的可维护性
    遵守开闭原则的软件,其稳定性高和延续性强,从而易于扩展和维护。

     

    2、里氏替换原则

    原则定义:

    继承必须确保超类(被继承的类称为超类,继承的类称为子类)所拥有的性质在子类中仍然成立。
    
    里氏替换原则主要阐述了有关继承的一些原则,也就是什么时候应该使用继承,什么时候不应该使用继承,以及其中蕴含的原理。里氏替换原是继承复用的基础,它反映了基类与子类之间的关系,是对开闭原则的补充,是对实现抽象化的具体步骤的规范。

    实现原理:

    1、子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法
    2、子类可以有自己的个性
    3、覆盖或实现父类的方法时输入参数可以被放大
    4、覆写或实现父类的方法时输出结果可以被缩小

    实例展示:

    1、子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法
    子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法,父类中凡是已经实现好的方法(相对于抽象方法而言),实际上是在设定一系列的规范和契约,虽然它不强制要求所有的子类必须遵从这些契约,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破坏。
    (略)
    
    2、子类可以有自己的个性
    在继承父类属性和方法的同时,每个子类也都可以有自己的个性,在父类的基础上扩展自己的功能。前面其实已经提到,当功能扩展时,子类尽量不要重写父类的方法,而是另写一个方法,所以对上面的代码加以更改,使其符合里氏替换原则。
    (略)
    
    3、覆盖或实现父类的方法时输入参数可以被放大
    当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
                                                    (String 继承于CharSequence)
    public class ParentClazz {
        public void say(String str) {
            System.out.println("parent execute say " + str);
        }
    }
    
    public class ChildClazz extends ParentClazz {
        public void say(CharSequence str) {
            System.out.println("child execute say " + str);
        }
    }
    // 执行结果:
    // parent execute say hello
    // parent execute say hello
    // 参数大小不一样,一直用的都是string,父类的
    
    4、覆写或实现父类的方法时输出结果可以被缩小
    当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。
    public abstract class Father {
        public abstract Map hello();
    }
    
    public class Son extends Father {
        @Override
        public Map hello() {
            HashMap map = new HashMap();
            System.out.println("son execute");
            return map;
        }
    }
    

    里式替换的作用:

    里氏替换原则是实现开闭原则的重要方式之一。
    它克服了继承中重写父类造成的可复用性变差的缺点。
    它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误,降低了代码出错的可能性。

     

    3、依赖倒置原则

    原则定义:

    依赖倒置原则的原始定义为:高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象。其核心思想是:要面向接口编程,不要面向实现编程。
    
    依赖倒置原则是实现开闭原则的重要途径之一,它降低了客户与实现模块之间的耦合。
    
    由于在软件设计中,细节具有多变性,而抽象层则相对稳定,因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类,而细节是指具体的实现类。
    
    使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给它们的实现类去完成。

    实现原理:

    依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性,所以我们在实际编程中只要遵循以下4点,就能在项目中满足这个规则。
    每个类尽量提供接口或抽象类,或者两者都具备。
    变量的声明类型尽量是接口或者是抽象类。
    任何类都不应该从具体类派生。
    使用继承时尽量遵循里氏替换原则。

    实例展示:

    public class T2 {
        public static void main(String[] args) {
            IDriver zhangsan = new Driver();
            Icar benz = new Benz();
            zhangsan.drive(benz);
    
            Icar bmw = new BMW();
            zhangsan.drive(bmw);
        }
    }
    
    interface IDriver {
        //    司机职责就是驾驶汽车
        public void drive(Icar car);
    }
    
    class Driver implements IDriver{
        //    司机职责就是驾驶汽车
        @Override
        public void drive(Icar car) {
            car.run();
        }
    }
    
    interface Icar {
        //    车的作用就是跑
        public void run();
    }
    
    class Benz implements Icar {
        //    车的作用就是跑
        @Override
        public void run() {
            System.out.println("奔驰车跑起来了");
        }
    }
    
    class BMW implements Icar {
        //    车的作用就是跑
        @Override
        public void run() {
            System.out.println("宝马车跑起来了");
        }
    }

    依赖倒置原则作用:

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

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 主要介绍了详解Java设计模式中的依赖倒置原则,针对面对对象编程中的抽象的运用,需要的朋友可以参考下
  • 本文实例讲述了PHP面向对象五大原则之依赖倒置原则(DIP)。分享给大家供大家参考,具体如下: 什么是依赖倒置呢?简单地讲就是将依赖关系倒置为依赖接口,具体概念如下: 1.上层模块不应该依赖于下层模块,它们共同...
  • 依赖倒置原则DIP(Dependency Inversion Principle) High level modules should not depend upon low level modules. Both shoulddepend upon abstractions. 高层模块不应该依赖于低层模块,二者都应该依赖于...
  • 依赖倒置原则讲解

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

    千次阅读 2019-03-03 12:48:00
    依赖倒转原则 【Dependence Inversion Principle】   定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。   问题由来:类A直接依赖类B,假如要将类A改为依赖类C...
  • 依赖倒置原则(设计模式原则)

    千次阅读 2018-01-14 00:02:27
    (Dependence Inversion Principle)定义: 高层模块不应该依赖底层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。//“抽象”指“接口或抽象类”,“细节”指“实现类” 在语言中表现:  ...
  • 依赖倒置原则(DIP)

    2021-06-27 21:06:08
    依赖倒置原则(The Dependency Inversion Principle)
  • 依赖倒置原则的理解

    2021-03-22 19:51:20
    依赖倒置原则的理解 1.问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;...
  • 依赖倒置原则的定义 依赖倒置原则(Dependence Inversion Principle,DIP)是 Object Mentor 公司总裁罗伯特·马丁(Robert C.Martin)于 1996 年在 C++ Report 上发表的文章。 依赖倒置原则的原始定义为:高层模块...
  • 面向对象六大原则——依赖倒置原则

    万次阅读 多人点赞 2018-08-13 10:56:49
    什么是依赖倒置原则(Dependence Inversion Principle, DIP)  依赖倒置原则的包含如下的三层含义: - 高层模块不应该依赖低层模块,两者都应该依赖其抽象 - 抽象不应该依赖细节 - 细节应该依赖抽象  每一个...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,809
精华内容 13,123
关键字:

依赖倒置原则

友情链接: clip.rar