接口的新理解与依赖注入

我以前对于java接口的理解，一直是觉得这个东西没有什么太大用处，不如抽象类，可有可无的一个东西。但一个东西既然存在一定有他的意义，今天我就看到了接口的一个重要用法。

首先毋庸置疑的是，java单继承的情况下，你只能继承一个类，但可以实现多个接口，这也是我一直以为的接口唯一的用法：在单继承不够用的情况下实现其他的接口。

然后是我现在才知道的，接口里声明的所有方法，在实现接口时都必须全部被实现——这可以强制实现该接口的类具有某一些特性。

这里举一个例子说明：例子来自spring实战这本书。

我们假设有一个继承Knight接口的类：

package Knight_Quest;

public class DamselRescuingKnight implements Knight{
    private RescueDamselQuest quest;
    
    public DamselRescuingKnight(){
        this.quest = new RescueDamselQuest();
    }
    @Override
    public void embarkOnQuest() {
        quest.embark();
    }
}

这个类便有一个问题，首先该骑士与这种类型的任务绑死在了一起，也就是说这个类作为一个类复用性非常差（甚至想到于一个对象）。

由于在构造方法直接自行创建了RescueDamselQuest()对象，所以相当于该Knight只能执行这一种任务——如果一个少女需要救援，那么这个Knight就能招之而来，但是如果有恶龙需要杀掉，有圆桌会议要开，那么这位Knight也就爱莫能助了（仅仅是因为在构造方法中直接创建了某一种特定的对象，使得两个类紧密的耦合在一起，无法分开）。更糟糕的是，在测试的时候，又会有一个新的问题——你无法保证在调用Knight类的embarkOnQuest()方法的时候，其下面的quest.embark()方法也能被正确的调用。所以这个类可以说是无法进行有效的测试。

所以我们就要使用依赖注入的思想来编写：

我们可以创建一个Quest接口，且强制实现该接口的类（各种quest）都必须实现embark方法（这个embark方法可以根据类的不同而不同）

public interface Quest {
    public void embark();
}

public class RescueDamselQuest implements Quest{
    @Override
    public void embark() {

    }
}

然后我们对BraveKnight进行改写：

public class BraveKnight implements Knight{
    private Quest quest;

    public BraveKnight(Quest quest){
        this.quest = quest;
    }
    @Override
    public void embarkOnQuest() {
        quest.embark();
    }
}

这样改造过的Knight就不同了，构造方法中传入的是Quest这一接口，这样一来，BraveKnight能够响应DamselRescuingQuest、DragonSlayQuet、RoundtableQuest等各种Quest接口的实现类。这时构造Knight，就不是由Knight自行创建某个对象，而是将各种quest对象作为构造器的参数传入——这就是依赖注入的方式之一。

这里的要点是 BraveKnight 没有与任何特定的 Quest 实现发生耦合。对它来说，被要求挑战的任务只要实现了 Quest 接口，那么具体是哪种类型的任务就无关紧要了。 这就是 DI(依赖注入) 所带来的最大收益——松耦合。

测试时只需要使用mock就行。