依赖倒置原则

本贴最后更新于 2179 天前,其中的信息可能已经沧海桑田

雪

2019 新年第一篇。

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

简介

姓名 :依赖倒置原则

英文名 :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 设计模式》

欢迎大家关注公众号 LieBrother,一起学习、进步!

  • B3log

    B3log 是一个开源组织,名字来源于“Bulletin Board Blog”缩写,目标是将独立博客与论坛结合,形成一种新的网络社区体验,详细请看 B3log 构思。目前 B3log 已经开源了多款产品:SymSoloVditor思源笔记

    1063 引用 • 3454 回帖 • 189 关注
  • 设计模式

    设计模式(Design pattern)代表了最佳的实践,通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

    200 引用 • 120 回帖
  • 依赖倒置原则
    1 引用 • 1 回帖
  • DIP
    1 引用 • 1 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • LieBrother
    作者

    设计模式系列文章第三篇:依赖倒置原则,欢迎一起交流