使用接口有什么好处
假设你有一个界面
public interface Change { void updateUser(); void deleteUser(); void helpUser(); } 我已经读过接口是Java实现多重inheritance的方式。 您实现了一个接口，然后您可以访问其方法。 我不明白的是，这些方法在界面中没有任何主体，所以你需要在课堂上给它们一个主体。 因此，如果您的接口由多个类实现，则需要在多个类中为该方法提供一个主体。 为什么这比在类中使用单独的方法更好，而不是实现接口？
我在大学的教授曾经给出了一个很好的轶事来描述多态性和封装。 它是这样的。
有谁知道汽水机是如何工作的？ （提示混淆了我们为什么甚至谈论这个问题的一瞥。）不是吗？ 让我告诉你。
你放弃你的改变，在机器内部是一个小猴子，他会计算你所有的变化，以确保你投入足够的钱。 当您按下苏打水的按钮时，会发出一点点光线告诉猴子您按下了哪个按钮，如果您输入了正确的更改，他会抓住您的选择并将其扔进小洞中以便您拿起苏打水。
这是封装的概念。 我们隐藏了汽水机的实施。 除非它有一个那些花哨，清晰的窗户让你看到内部，你真的不知道它是如何工作的。 所有你知道的是，你付了一些现金，你按下一个按钮，如果你放入足够的，你得到你的饮料。
除此之外，您知道如何使用汽水机的界面 ，因此只要机器的界面遵循通常的汽水机界面，您就可以使用它。 这称为接口合约。 机器可以将来自南极洲的饮料带到传送带上，只要你拿到饮料，感冒就可以得到改变。
多态性是这样的想法，当你使用苏打水机界面时，它可能会做不同的事情。 这就是封装和多态性密切相关的原因。 在多态性方面，你所知道的就是你正在使用一个可以改变的SodaMachine实现，因此，可以在幕后完成不同的事情。 这导致了多态性的驱动概念，即一个对象SodaMachine实际上充当MonkeySodaMachine和ConveyorSodaMachine具体取决于接口背后的机器。
可能不是逐字逐句，但足够接近。 从本质上讲，它归结为两个概念： 多态和封装 。 如果您想要澄清，请告诉我。
它将调用者期望的内容与实现区分开来。 您可以在不了解实现的情况下调用一组纯方法。 事实上，像JMS和JDBC这样的库提供了没有任何实现的接口。
这种分离意味着您不需要知道任何实际实现的类。
为什么这比在类中使用单独的方法更好，而不是实现接口？
因为如果类C实现了接口I ，那么每当I ，你都可以使用C 。 如果您没有实现该接口，则无法执行此操作（即使您提供了接口要求的所有适当方法）：
interface I { void foo(); } class C1 implements I { public void foo() { System.out.println("C1"); } } class C2 { // C2 has a 'foo' method, but does not implement I public void foo() { System.out.println("C2"); } } ... class Test { public static void main(String[] args) { I eye1 = new C1(); // works I eye2 = new C2(); // error! } }
界面允许您保证存在某些方法并返回所需的类型。 当编译器知道这一点时，它可以使用该假设来处理未知类，就好像它们具有某些已知行为一样。 例如，可比较的接口保证实现类能够compareTo（）一些类似的对象并返回一个int。
这意味着您可以比较实现此接口的任何内容 – 因此您可以对可比较的任何内容进行排序，而不是编写一个方法来对字符串进行排序，而另一个方法对整数进行排序，另一个对SortledBoxesOfBooks进行排序。
接口本质上保证inheritance它的所有方法都有它的方法，这样你就可以安全地在接口中调用一个inheritance它的方法。
它使得使用接口定义API变得更加容易，因此接口的所有具体实现都在每个类中提供了预期的方法。
它还提供了一种实现多重inheritance的方法，这是不可能的（在Java中）具有直接类inheritance。