问:——……“你能使用任何实现接口的类吗?” A:是的。 问:——……“你什么时候需要这样做?” 答:-每次你都需要一个实现接口的类。

注意:我们不能实例化一个没有被类实现的接口- True。

为什么? 因为接口只有方法原型，没有定义(只有函数名，没有它们的逻辑)

AnIntf anInst = new class(); //我们可以这样做，只有当类实现AnIntf。 // anInst将有类引用。

注意:现在我们可以理解如果Bclass和Cclass实现相同的Dintf会发生什么。

Dintf bInst = new Bclass();  
// now we could call all Dintf functions implemented (defined) in Bclass.

Dintf cInst = new Cclass();  
// now we could call all Dintf functions implemented (defined) in Cclass.

我们拥有:相同的接口原型(接口中的函数名)，调用不同的实现。

参考书目: 原型——维基百科

面向接口而不是实现的代码与Java无关，也与它的接口构造无关。

这个概念是在模式/四人帮的书中突出的，但很可能在那之前就已经存在了。这个概念在Java出现之前就已经存在了。

Java Interface构造的创建就是为了帮助实现这一想法(以及其他一些事情)，人们过于关注作为意义中心的构造，而不是最初的意图。然而，这也是为什么我们在Java、c++、c#等语言中有公共和私有方法和属性的原因。

It means just interact with an object or system's public interface. Don't worry or even anticipate how it does what it does internally. Don't worry about how it is implemented. In object-oriented code, it is why we have public vs. private methods/attributes. We are intended to use the public methods because the private methods are there only for use internally, within the class. They make up the implementation of the class and can be changed as required without changing the public interface. Assume that regarding functionality, a method on a class will perform the same operation with the same expected result every time you call it with the same parameters. It allows the author to change how the class works, its implementation, without breaking how people interact with it.

And you can program to the interface, not the implementation without ever using an Interface construct. You can program to the interface not the implementation in C++, which does not have an Interface construct. You can integrate two massive enterprise systems much more robustly as long as they interact through public interfaces (contracts) rather than calling methods on objects internal to the systems. The interfaces are expected to always react the same expected way given the same input parameters; if implemented to the interface and not the implementation. The concept works in many places.

不要认为Java接口与“面向接口编程，而不是面向实现”的概念有什么关系。它们可以帮助应用概念，但它们不是概念。

接口类似于契约，您希望实现类实现在契约(接口)中编写的方法。由于Java不提供多重继承，“编程到接口”是实现多重继承的好方法。

如果您有一个类a，它已经扩展了其他一些类B，但是您希望这个类a也遵循某些指导方针或实现某个契约，那么您可以通过“编程到接口”策略来实现。

你应该看看反转控制:

Martin Fowler:控制反转容器和依赖注入模式 维基百科:控制反转

在这种情况下，你不会这样写:

IInterface classRef = new ObjectWhatever();

你可以这样写:

IInterface classRef = container.Resolve<IInterface>();

这将进入容器对象中基于规则的设置，并为您构造实际对象，该对象可以是ObjectWhatever。重要的是，您可以将此规则替换为完全使用另一种类型对象的规则，而您的代码仍然可以工作。

如果我们不考虑IoC，那么您可以编写的代码知道它可以与执行特定操作的对象进行对话，但不知道是哪种类型的对象或它如何执行操作。

这将在传递参数时派上用场。

至于你带圆括号的问题“另外，你如何编写一个方法来接受一个实现接口的对象?”这可能吗?”，在c#中，你可以简单地使用接口类型作为参数类型，如下所示:

public void DoSomethingToAnObject(IInterface whatever) { ... }

这直接插入到“与做特定事情的对象对话”中。上面定义的方法知道从对象中期望得到什么，它实现了IInterface中的所有内容，但它并不关心它是哪种类型的对象，只关心它遵守契约，这就是接口。

例如，你可能对计算器很熟悉，也可能在你的生活中使用过不少计算器，但大多数时候它们都是不同的。另一方面，你知道标准计算器应该如何工作，所以你能够使用所有的计算器，即使你不能使用每个计算器都没有的特定功能。

这就是界面的美妙之处。你可以写一段代码，它知道它会得到传递给它的对象，它可以从这些对象中期待特定的行为。它并不关心它是什么类型的对象，只关心它支持所需的行为。

让我给你一个具体的例子。

我们为windows窗体定制了翻译系统。这个系统循环遍历表单上的控件，并翻译每个控件中的文本。这个系统知道如何处理基本的控件，比如拥有文本属性的控件类型，以及类似的基本东西，但对于任何基本的东西，它都做不到。

现在，由于控件继承自我们无法控制的预定义类，我们可以做以下三件事之一:

为我们的翻译系统提供支持，以检测它正在使用哪种类型的控件，并翻译正确的位(维护的噩梦) 将支持构建到基类中(不可能，因为所有控件都继承自不同的预定义类) 添加接口支持

所以是nr. 3。我们所有的控件都实现了ILocalizable，这是一个提供给我们一个方法的接口，能够将“本身”转换为翻译文本/规则的容器。因此，表单不需要知道它找到了哪种类型的控件，只需要知道它实现了特定的接口，并且知道可以调用某个方法来本地化该控件。

为一个接口编程就是在说:“我需要这个功能，我不在乎它来自哪里。”

Consider (in Java), the List interface versus the ArrayList and LinkedList concrete classes. If all I care about is that I have a data structure containing multiple data items that I should access via iteration, I'd pick a List (and that's 99% of the time). If I know that I need constant-time insert/delete from either end of the list, I might pick the LinkedList concrete implementation (or more likely, use the Queue interface). If I know I need random access by index, I'd pick the ArrayList concrete class.

这里有一些关于这个问题的很好的答案，涉及到各种关于接口和松耦合代码、控制反转等等的细节。有一些相当令人兴奋的讨论，所以我想借此机会把事情分解一下，以理解为什么界面是有用的。

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?" 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.

例如，假设你有一款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的契约——这个契约很简单。你只需要变得烦人。在这方面，我们可以建立以下模型:

class DiningRoom {

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

    void ServeDinner() {
        when diningPeople are eating,

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

这里我们有一个餐厅，可以接待许多食客和一些害虫——注意界面的使用。这意味着在我们的小世界中，害虫数组的成员实际上可以是Telemarketer对象或HouseFly对象。

The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat. 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. 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.

这个非常人为的伪代码示例(比我预期的要长得多)只是为了说明一些事情，这些事情最终为我打开了一盏灯，让我知道什么时候可以使用接口。我为这个例子的愚蠢提前道歉，但希望它有助于您的理解。而且，可以肯定的是，您在这里收到的其他回答确实涵盖了当今在设计模式和开发方法中使用接口的全部范围。