设计原则之依赖倒置原则

最新推荐文章于 2020-12-20 16:13:49 发布

原创最新推荐文章于 2020-12-20 16:13:49 发布 · 230 阅读

0 ·

CC 4.0 BY-SA版权

本文为博主原创文章，转载请注明出处。

文章标签：

#依赖导致 #设计模式 #Java #编程

Java 专栏收录该内容

15 篇文章

订阅专栏

本文探讨了依赖倒置原则，强调面向抽象编程以提高代码的可扩展性。通过实例说明，传统的实现方式在需求变化时会导致大量重复类的创建，而遵循依赖倒置原则，利用接口可以更灵活地应对需求变化，简化代码结构，便于维护。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言：最近看到一篇阮一峰老师的研究生文凭的文章。说研究生论理论比不上博士，论实践比不上工作两年的本科同学。对于这一点自己也有一点个人的观点，个人认为只要stay hungry, stay foolish读两年研究生。那研究生会是最好的学历，拥有一定的研究能力，也有不错的实践能力。废话不多说，回到正题，聊聊依赖倒置原则

1、依赖倒置原则是什么

依赖倒置原则告诉我们最重要的一个问题就是面向抽象编程。这里的抽象可以是抽象类或者接口，我们一般通过接口的方式。

2、依赖倒置原则的应用

我们有一个司机张三，然后让他开宝马，如果我们不考虑依赖导致原则，我们会下面这样写
宝马类

public class BMW {
    public void run() {
        System.out.println("我是宝马，我正在行驶...");
    }
}

张三类

public class ZhangSan {
    public void drive(BMW Bmw) {
        System.out.println("我是司机张三");
        Bmw.run();
    }
}

客户端

public static void main(String[] args) {
    ZhangSan zhangSan = new ZhangSan();
    BMW bmw = new BMW();
    zhangSan.drive(bmw);
}

上面看上去似乎很完美，但是我们有一点一定要注意，所有的设计模式都是为了后期的可扩展性。如果我们这里要求张三去开奔驰，那么我们又需要建立一个奔驰类，如果开其他车，又需要其他类。另外如果我们把司机换成李四，那么又需要建一个李四的类。这肯定是我们不希望看到的，因此就出现了依赖导致原则，我们来看看使用依赖导致原则是怎样实现上面的需求的。
汽车接口类

public interface ICar {
    public void run();
}

司机接口类

public interface IDriver {
    public void drive(ICar car);
}

汽车实现类

public class Car implements ICar{
    private String carName = "";
    public Car(String carName) {
        this.carName = carName;
    }
    public void run() {
        System.out.println("我是"+this.carName+",我正在行驶...");
    }
}

司机实现类

public class Driver implements IDriver{
    private String driverName = "";
    public Driver(String driverName) {
        this.driverName = driverName;
    }
    public void drive(ICar car) {
        System.out.println("我是司机"+this.driverName);
        car.run();
    }
}

客户端

public static void main(String[] args) {
    IDriver zhangSan = new Driver("张三");
    IDriver liSi = new Driver("李四");
    ICar Benz = new Car("奔驰");
    ICar Bmw = new Car("宝马");
    zhangSan.drive(Benz);
    liSi.drive(Bmw);
}

使用了依赖倒置原则以后，我们可以明显的感觉到好了很多

3、里式替换原则的优势

需求改变的时候，我们可以灵活变通
代码结构比较清晰，后面的人维护比较轻松

4、总结

设计模式虽好，但是不要为了使用设计模式而使用设计模式。在很多小型项目中，我们过度使用设计模式，只会让本来简单清晰的结构变得复杂臃肿。想起自己在做的一个项目，导师让自己那样做，自己却说这样不好，需要使用一点设计模式，这样可扩展性更好。其实导师已经把很多东西花了很多时间封装好了，自己却看到不去看一眼，想想自己真是too young, too simple。在这里向导师表示敬意