对于接口有一些困惑，接口既不能定义方法体具体内容，又在继承后都被覆盖。多重继承这种空方法意义有多大？

程序中，接口是实现多态的一种方法

解决了java中只能单继承的问题。(对多继承进行了优化)
A：类与类：只能是单继承。
B：接口与接口：可以是单继承，也可以是多继承。
C：类与接口：可以是单实现，也可以是多实现。

接口的出现主要是为了解决java中单继承的局限性。像Runnable接口，如果没有接口，我们写的类要想成为一个线程类，就只能继承Thread，想要继承其他的类，实现更多的功能是办不到的。接口的功能还体现在多态上，虽然它没有具体的方法实现，但是我们在定义方法的参数的时候，可以定义一个父接口，当我们在使用的时候，可以传入任意其子类。这也是接口的功能吧。

若还有问题，继续追问； 没有的话，将帖子分类改成【已解决】哦~

点进自己的帖子，编辑->标题左侧有下拉菜单->改变分类->保存~

http://bbs.itheima.com/thread-44617-1-1.html
看看老师写的这个帖子吧，应该对你很有帮助！

接口把方法的特征和方法的实现分割开来。这种分割体现在接口常常代表一个角色，它包装与该角色相关的操作和属性，而实现这个接口的类便是扮演这个角色的演员。一个角色由不同的演员来演，而不同的演员之间除了扮演一个共同的角色之外，并不要求其它的共同之处。

当学习过设计模式的时候，才发现接口和抽象类是如此的重要。它做为抽象化和解耦的一个重要工具。

就比如一个简单的他的功能体现



//公共接口，吃饭动作。
interface eat{

void ff();

}

class student implements  eat
{
  void ff()
{
system.out.println("学生吃");
}
}
class Teacher implements  eat
{
  void ff()
{
system.out.println("老师吃");
}
}


在主函数中就可以使用


eat a  = new Student();
eat b = new Teacher();
eat c  = 从xml中动态得到对象
当然这些定义可以在xml中动态的指定，可以使当你增加一个比如工人类的时候，就不用修改原有的代码。是程序更加具有扩展性。
建议学习一下设计模式。
接口的好处就明显了

Java中的接口是一系列方法的声明，是一些方法特征的集合，一个接口只有方法的特征没有方法的实现，因此这些方法可以在不同的地方被不同的类实现，而这些实现可以具有不同的行为（功能）。接口把方法的特征和方法的实现分割开来。这种分割体现在接口常常代表一个角色，它包装与该角色相关的操作和属性，而实现这个接口的类便是扮演这个角色的演员。一个角色由不同的演员来演，而不同的演员之间除了扮演一个共同的角色之外，并不要求其它的共同之处。
比如：Java是一种单继承的语言，一般情况下，哪个具体类可能已经有了一个超类，解决是给它的父类加父类，或者给它父类的父类加父类，直到移动到类等级结构的最顶端。这样一来，对一个具体类的可插入性的设计，就变成了对整个等级结构中所有类的修改。而接口是可插入性的保证，在一个等级结构中的任何一个类都可以实现一个接口，这个接口会影响到此类的所有子类，但不会影响到此类的任何超类。此类将不得不实现这个接口所规定的方法，而其子类可以从此类自动继承这些方法，当然也可以选择置换掉所有的这些方法，或者其中的某一些方法，这时候，这些子类具有了可插入性(并且可以用这个接口类型装载，传递实现了他的所有子类)。
我们关心的不是那一个具体的类，而是这个类是否实现了我们需要的接口。
接口提供了关联以及方法调用上的可插入性，软件系统的规模越大，生命周期越长，接口使得软件系统的灵活性和可扩展性，可插入性方面得到保证。

定义接口编程也是一种设计模式
比如集合框架
Collection定义了一种规范，他的子类，都去实现 这样用起来方便
.关于接口的理解。
接口从更深层次的理解，应是定义（规范，约束）与实现（名实分离的原则）的分离。
我们在一般实现一个系统的时候，通常是将定义与实现合为一体，不加分离的，我认为最为理想的系统设计规范应是所有的定义与实现分离，尽管这可能对系统中的某些情况有点麻烦。
接口的本身反映了系统设计人员对系统的抽象理解。
接口应有两类：第一类是对一个体的抽象，它可对应为一个抽象体(abstract class)；
第二类是对一个体某一方面的抽象，即形成一个抽象面（interface）；
一个体有可能有多个抽象面。
抽象体与抽象面是有区别的。
2.设计接口的另一个不可忽视的因素是接口所处的环境(context,environment)，系统论的观点：环境是系统要素所处的空间与外部影响因素的总和。任何接口都是在一定的环境中产生的。因此环境的定义及环境的变化对接口的影响是不容忽视的，脱离原先的环境，所有的接口将失去原有的意义。
3.按照组件的开发模型（3C），它们三者相辅相成，各司一面，浑然一体，缺一不可。
面向对象是指，我们考虑问题时，以对象为单位，考虑它的属性及方法
面向过程是指，我们考虑问题时，以一个具体的流程（事务过程）为单位，考虑它的实现
接口设计与非接口设计是针对复用技术而言的，与面向对象（过程）不是一个问题
UML里面所说的interface是协议的另一种说法。并不是指com的interface，CORBA的interface，Java的interface，Delphi的interface，人机界面的interface或NIC的interface。
在具体实现中，是可以把UML的interface实现为语言的interface，分布式对象环境的interface或其它什么interface，但就理解UML的interface而言，指的是系统每部分的实现和实现之间，通过interface所确定的协议来共同工作。
面向interface编程，原意是指面向抽象协议编程，实现者在实现时要严格按协议来办。面向对象编程是指面向抽象和具象。抽象和具象是矛盾的统一体，不可能只有抽象没有具象。一般懂得抽象的人都明白这个道理。 但有的人只知具象却不知抽象为何物。 　所以只有interface没有实现，或只有实现而没有interface者是没有用的，反OO的。
所以还是老老实实面向对象编程，面向协议编程，或者什么都不面向，老老实实编程。
但是我很讨厌讨论这样的术语，不如我们谈谈什么叫面向领导的编程？面向用户的编程？领导和用户有时都很BT，我们就面向BT编程？
选择Java接口还是抽象类
很多人有过这样的疑问：为什么有的地方必须使用接口而不是抽象类，而在另一些地方，又必须使用抽象类而不是接口呢？或者说，在考虑Java类的一般化问题时，很多人会在接口和抽象类之间犹豫不决，甚至随便选择一种。
实际上接口和抽象类的选择不是随心所欲的。要理解接口和抽象类的选择原则，有两个概念很重要：对象的行为和对象的实现。如果一个实体可以有多种实现方式，则在设计实体行为的描述方式时，应当达到这样一个目标：在使用实体的时候，无需详细了解实体行为的实现方式。也就是说，要把对象的行为和对象的实现分离开来。既然Java的接口和抽象类都可以定义不提供具体实现的方法，在分离对象的行为和对象的实现时，到底应该使用接口还是使用抽象类呢？
通过抽象类建立行为模型
在接口和抽象类的选择上，必须遵守这样一个原则：行为模型应该总是通过接口而不是抽象类定义。为了说明其原因，下面试着通过抽象类建立行为模型，看看会出现什么问题。
假设要为销售部门设计一个软件，这个软件包含一个“发动机”（Motor）实体。显然无法在发动机对象中详细地描述发动机的方方面面，只能描述某些对当前软件来说重要的特征。至于发动机的哪些特征是重要的，则要与用户（销售部门）交流才能确定。
销售部门的人要求每一个发动机都有一个称为马力的参数。对于他们来说，这是惟一值得关心的参数。基于这一判断，可以把发动机的行为定义为以下行为。
行为1：查询发动机的马力，发动机将返回一个表示马力的整数。
虽然现在还不清楚发动机如何取得马力这个参数，但可以肯定发动机一定支持这个行为，而且这是所有发动机惟一值得关注的行为特征。这个行为特征既可以用接口定义，也可以用抽象类定义。为了说明用抽象类定义可能出现的问题，下面用抽象类建立发动机的行为模型，并用Java方法描述行为1，代码如下：
代码
public abstract Motor{
abstract public int getHorsepower();
}

接口只是继承的延续，java继承的特性是有局限性的，可以通过java进行扩展。至于在使用方面的一些硬性要求只能记住。就像1+1为什么等于2一样。

我举个形象点的例子把！就像建房子那样，你建的时候，门口你还不知道用哪种门，哪个牌子的门，所以你就预留个位置给装这扇门。到你买到了门，这时候你就可以装这扇门了。这有点像接口的意思。懂了么？

就是当前类继承一个类后，不能再继承其他类
而实现一个接口后，还可以在实现多个接口
例： class A implements  B,implements  C

主要是定义一个标准，当实现这个接口是就是实现了这个标准，这时可以面向接口编程，可以提高代码的灵活性。