依赖倒置原则

2017-01-20  本文已影响0人  我的头好疼

依赖倒置原则


定义

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(Object-Oriented Design,面向对象设计)的精髓之一。

依赖倒置原则优点

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

image
下面是源代码
class Benz {
    public void run(){
        System.out.println("奔驰汽车开始运行...");
    }
}

class Driver {
    public void drive(Benz benz){
        benz.run();
    }

}

public class Client {

    public static void main(String args[]){
        Benz benz = new Benz();
        Driver zs = new Driver();
        zs.drive(benz);
    }
}

分析

通过上面的代码,知道如果需要司机重新开别的车,显然需要改司机类,汽车类,这样的开发成本是非常高的,同时也违背了依赖倒置的原则,下面引入依赖倒置原则重新设计开汽车的方法:

image
抽象是对实现的约束,对依赖者而言,也是一种契约,不仅仅约束自己,还同时约束自己与外部的关系,其目的是保证所有的细节不脱离契约的范畴,确保约束双方按照既定的契约(抽象)共同发展,只要抽象这根基线在,细节就脱离不了这个圈圈,始终让你的对象做到“言必信,行必果”。

依赖的三种写法

1、构造函数注入

在类中通过构造函数声明依赖对象,按照依赖注入的说法,这种方式叫做构造函数注入。
按照这种方式的注入,IDriver和Driver的程序如下所示:

public interface IDriver {
    public void drive();
}
public class Drive implements IDriver {

    private ICar car;

    public Drive(ICar car){
        this.car = car;
    }

    public void drive() {
        this.car.run();
    }
}
public class Benz implements ICar{
    public void run(){
        System.out.println("奔驰汽车开始运行...");
    }
}
public class Drive implements IDriver {

    private ICar car;

    public Drive(ICar car){
        this.car = car;
    }

    public void drive() {
        this.car.run();
    }
}
public class Client {

    public static void main(String args[]){
        ICar car = new Benz();
        ICar bmw = new BMW();
        IDriver zs = new Drive(car);
        zs.drive();

        zs = new Drive(bmw);
        zs.drive();
    }
}

2、set注入

set注入其实就是set方法注入
如下所示:

public interface IDriver {
    // 注入汽车接口
    public void setCar(ICar car);

    public void drive();
}
public class Drive implements IDriver {

    private ICar car;

    // 通过set注入汽车接口
    public void setCar(ICar car) {
        this.car = car;
    }
    // 司机不用关心自己驾驶的是什么汽车
    public void drive() {
        this.car.run();
    }
}
public class Benz implements ICar{
    public void run(){
        System.out.println("奔驰汽车开始运行...");
    }
}
public class Drive implements IDriver {

    private ICar car;

    public Drive(ICar car){
        this.car = car;
    }

    public void drive() {
        this.car.run();
    }
}
public class Client {

    public static void main(String args[]){
        ICar benz = new Benz();
        ICar bmw = new BMW();
        IDriver zs = new Drive();
        zs.setCar(benz);
        zs.drive();

        zs.setCar(bmw);
        zs.drive();

    }
}

3、接口声明依赖对象

刚才的分析就是接口声明依赖对象,代码如下所示:

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

    @Override
    public void drive(ICar car) {
        car.run();
    }
}
public interface ICar {
    void run();
}
public class BMW  implements ICar{
    @Override
    public void run() {
        System.out.println("宝马汽车开始运行...");
    }
}
public class Benz implements ICar{
    public void run(){
        System.out.println("奔驰汽车开始运行...");
    }
}
public class Client {

    public static void main(String args[]){
        ICar benz = new Benz();
        ICar bmw = new BMW();
        IDriver zs = new Drive();
        zs.drive(benz);

        zs.drive(bmw);
    }
}

总结

依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合
所以我们需要遵循以下几点:

  1. 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备
    这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置。
  2. 变量的表面类型尽量是接口或者是抽象类
    很多书上说变量的类型一定要是接口或者是抽象类,这个有点绝对化了,比如一个工具类,xxxUtils一般是不需要接口或是抽象类的。还有,如果你要使用类的clone方法,就必须使用实现类,这个是JDK提供的一个规范。
  3. 任何类都不应该从具体类派生
    如果一个项目处于开发状态,确实不应该有从具体类派生出子类的情况,但这也不是绝对的,因为人都是会犯错误的,有时设计缺陷是在所难免的,因此只要不超过两层的继承都是可以忍受的。特别是负责项目维护的同志,基本上可以不考虑这个规则,为什么?维护工作基本上都是进行扩展开发,修复行为,通过一个继承关系,覆写一个方法就可以修正一个很大的Bug,何必去继承最高的基类呢?(当然这种情况尽量发生在不甚了解父类或者无法获得父类代码的情况下。)
  4. 尽量不要覆写基类的方法
    如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。
  5. 结合里氏替换原则使用
上一篇下一篇

猜你喜欢

热点阅读