language-agnostic - “编程到接口”是什么意思？(What does it mean to “program to an interface”?)

Question

I have seen this mentioned a few times and I am not clear on what it means.

(我已经看过几次这个问题了，我不清楚它是什么意思。)

When and why would you do this?

(您何时以及为什么要这样做？)

I know what interfaces do, but the fact I am not clear on this makes me think I am missing out on using them correctly.

(我知道接口的作用，但是我对此不清楚，这使我觉得我错过了正确使用它们的机会。)

Is it just so if you were to do:

(如果要这样做，是否只是这样：)

IInterface classRef = new ObjectWhatever()

You could use any class that implements IInterface ?

(您可以使用实现IInterface任何类吗？)

When would you need to do that?

(您什么时候需要这样做？)

The only thing I can think of is if you have a method and you are unsure of what object will be passed except for it implementing IInterface .

(我唯一能想到的是，如果您有一个方法，并且不确定要实现IInterface对象，则不确定该对象将被传递。)

I cannot think how often you would need to do that.

(我不认为您需要多久这样做一次。)

Also, how could you write a method that takes in an object that implements an interface?

(另外，您如何编写一个接受实现接口的对象的方法？)

Is that possible?

(那可能吗？)

  ask by Damien translate from so

Answer 1

There are some wonderful answers on here to this questions that get into all sorts of great detail about interfaces and loosely coupling code, inversion of control and so on.

(对于这些问题，这里有一些奇妙的答案，涉及关于接口和松耦合代码，控制反转等的各种详细信息。)

There are some fairly heady discussions, so I'd like to take the opportunity to break things down a bit for understanding why an interface is useful.

(这里有一些相当令人头疼的讨论，所以我想借此机会分解一下内容，以了解界面为什么有用。)

When I first started getting exposed to interfaces, I too was confused about their relevance.

(当我第一次接触接口时，我也对接口的相关性感到困惑。)

I didn't understand why you needed them.

(我不明白你为什么需要他们。)

If we're using a language like Java or C#, we already have inheritance and I viewed interfaces as a weaker form of inheritance and thought, "why bother?"

(如果我们正在使用Java或C＃之类的语言，那么我们已经拥有继承，我将接口视为一种较弱的继承形式，并认为“为什么要打扰？”)

In a sense I was right, you can think of interfaces as sort of a weak form of inheritance, but beyond that I finally understood their use as a language construct by thinking of them as a means of classifying common traits or behaviors that were exhibited by potentially many non-related classes of objects.

(从某种意义上说我是对的，您可以将接口视为一种较弱的继承形式，但除此之外，我最终通过将它们视为对常见的特征或行为进行分类的一种手段，最终将它们用作语言构造。可能有许多不相关的对象类别。)

For example -- say you have a SIM game and have the following classes:

(例如，假设您有一个SIM卡游戏，并且具有以下课程：)

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

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

Clearly, these two objects have nothing in common in terms of direct inheritance.

(显然，就直接继承而言，这两个对象没有共同点。)

But, you could say they are both annoying.

(但是，您可以说它们都很烦人。)

Let's say our game needs to have some sort of random thing that annoys the game player when they eat dinner.

(假设我们的游戏需要某种随机的东西 ，使玩家在吃晚餐时会感到烦恼。)

This could be a HouseFly or a Telemarketer or both -- but how do you allow for both with a single function?

(这可能是HouseFly或Telemarketer HouseFly ，或两者都有-但是您如何同时使用单一功能呢？)

And how do you ask each different type of object to "do their annoying thing" in the same way?

(以及您如何要求每种不同类型的对象以相同的方式“做烦人的事情”？)

The key to realize is that both a Telemarketer and HouseFly share a common loosely interpreted behavior even though they are nothing alike in terms of modeling them.

(要实现的关键是， Telemarketer HouseFly和HouseFly共享一个松散的通用行为，即使它们在建模方面并不相同。)

So, let's make an interface that both can implement:

(因此，让我们创建一个可以实现的接口：)

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();
    }
}

We now have two classes that can each be annoying in their own way.

(现在，我们有两个类，每个类都可能以自己的方式令人讨厌。)

And they do not need to derive from the same base class and share common inherent characteristics -- they simply need to satisfy the contract of IPest -- that contract is simple.

(而且，他们不需要从相同的基类派生出来并共享共同的固有特性-他们只需要满足IPest的合同-该合同IPest简单。)

You just have to BeAnnoying .

(您只需要BeAnnoying 。)

In this regard, we can model the following:

(在这方面，我们可以建立以下模型：)

class DiningRoom {

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

    void ServeDinner() {
        when diningPeople are eating,

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

Here we have a dining room that accepts a number of diners and a number of pests -- note the use of the interface.

(在这里，我们有一间餐厅，可以容纳许多食客和许多害虫-请注意该界面的使用。)

This means that in our little world, a member of the pests array could actually be a Telemarketer object or a HouseFly object.

(这意味着在我们的小世界中， pests阵列的成员实际上可能是Telemarketer HouseFly对象或“ HouseFly对象。)

The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat.

(提供晚餐时，应该叫ServeDinner方法，而我们在饭厅里的人应该就餐。)

In our little game, that's when our pests do their work -- each pest is instructed to be annoying by way of the IPest interface.

(在我们的小游戏中，这是我们的害虫发挥作用的时候-通过IPest界面指示每种害虫都令人讨厌。)

In this way, we can easily have both Telemarketers and HouseFlys be annoying in each of their own ways -- we care only that we have something in the DiningRoom object that is a pest, we don't really care what it is and they could have nothing in common with other.

(这样，我们可以轻松地使Telemarketers HouseFlys和HouseFlys都以各自不同的方式烦恼-我们只关心在DiningRoom对象中是否有某种有害生物，我们不在乎它到底是什么，他们可以没有其他共同点。)

This very contrived pseudo-code example (that dragged on a lot longer than I anticipated) is simply meant to illustrate the kind of thing that finally turned the light on for me in terms of when we might use an interface.

(这个非常人为的伪代码示例（比我预期的拖了更长的时间）仅是为了说明最终使我了解何时使用接口的那种事情。)

I apologize in advance for the silliness of the example, but hope that it helps in your understanding.

(对于该示例的愚蠢行为，我事先表示歉意，但希望它对您的理解有所帮助。)

And, to be sure, the other posted answers you've received here really cover the gamut of the use of interfaces today in design patterns and development methodologies.

(而且，可以肯定的是，您在此处收到的其他已发布答案确实涵盖了当今在设计模式和开发方法中使用接口的范围。)