“编程到一个接口”是什么意思？

Question

这点我见过提过几次，但我不清楚是甚么意思。你什么时候为什么要这么做？

我知道接口是做什么的，但我不清楚这一点的事实使我认为我错过了正确使用它们。

如果你要做：

IInterface classRef = new ObjectWhatever()

您可以使用任何实现iinterface的类？你什么时候需要这么做？我唯一能想到的是，如果您有一个方法，但您不确定会传递什么对象，除了它实现iinterface。我想不出你需要多长时间这样做一次。

另外，如何编写一个方法来接受一个实现接口的对象呢？有可能吗？

Answer 1

这里有一些关于这些问题的精彩答案，这些问题涉及到各种关于接口、松散耦合代码、控制反转等等的非常详细的细节。有一些相当激动人心的讨论，所以我想利用这个机会把事情分解一下，以理解为什么接口是有用的。

当我刚开始接触接口时，我也对它们的相关性感到困惑。我不明白你为什么需要它们。如果我们使用的是像Java或C#这样的语言，我们已经有了继承，而我把接口看作是一种较弱的继承形式，并想，“何必费心呢？”从某种意义上说，我是对的，你可以把接口看作是一种弱的继承形式，但除此之外，我最终理解了它们作为一种语言构造的用途，把它们看作是一种对对象的许多潜在的非相关类所表现出的共同特征或行为进行分类的手段。

例如--假设您有一个SIM卡游戏，并且有以下类：

class HouseFly inherits Insect {
    void FlyAroundYourHead(){}
    void LandOnThings(){}
}

class Telemarketer inherits Person {
    void CallDuringDinner(){}
    void ContinueTalkingWhenYouSayNo(){}
}

显然，这两个对象在直接继承方面没有任何共同之处。但是，你可以说他们都很烦人。

比方说我们的游戏需要有某种随机的东西，当游戏玩家吃晚餐的时候会让他们感到恼火。这可能是housefly或telemarketer或者两者兼有--但是如何在一个函数中同时使用这两种功能呢？你如何要求每一个不同类型的对象以同样的方式“做他们讨厌的事情”？

要认识到的关键是，Telemarketer和Housefly共享一个共同的松散解释的行为，尽管它们在建模方面并不相同。所以，让我们制作一个两者都可以实现的接口：

interface IPest {
    void BeAnnoying();
}

class HouseFly inherits Insect implements IPest {
    void FlyAroundYourHead(){}
    void LandOnThings(){}

    void BeAnnoying() {
        FlyAroundYourHead();
        LandOnThings();
    }
}

class Telemarketer inherits Person implements IPest {
    void CallDuringDinner(){}
    void ContinueTalkingWhenYouSayNo(){}

    void BeAnnoying() {
        CallDuringDinner();
        ContinueTalkingWhenYouSayNo();
    }
}

我们现在有两个类，每一个都能以各自的方式让人讨厌。而且它们不需要派生自同一个基类并共享共同的固有特性--它们只需要满足ipest的约定--该约定很简单。你只需要beannoying。在这方面，我们可以建模如下：

class DiningRoom {

    DiningRoom(Person[] diningPeople, IPest[] pests) { ... }

    void ServeDinner() {
        when diningPeople are eating,

        foreach pest in pests
        pest.BeAnnoying();
    }
}

这里，我们有一个餐厅，它接受了许多食客和许多害虫--请注意接口的使用。这意味着在我们的小世界中，pathers数组的一个成员实际上可能是Telemarketer对象或Housefly对象。

servedinner方法是在提供晚餐并且我们在餐厅的人应该吃饭的时候调用的。在我们的小游戏中，有害程序就是在这个时候完成它们的工作的--每个有害程序都通过ipest接口被指示为令人讨厌的。这样，我们就可以很容易地使telemarketers和houseflys都以各自的方式令人讨厌--我们只关心diningroom对象中有什么东西是有害的，我们并不真正关心它是什么，而且它们可能与其他对象没有任何共同之处。

这个非常做作的伪代码示例（拖得比我预想的要长得多）只是想要说明，在我们何时可以使用接口的问题上，什么事情最终为我打开了灯。我提前为这个例子的愚蠢道歉，但希望它有助于你的理解。而且，可以肯定的是，您在这里收到的其他贴出的答案确实涵盖了当今在设计模式和开发方法中使用接口的所有方面。