看到有人讨论接口存在的意义,什么设计模式啊,什么依赖注入啊,什么什么的,专家级的语言好复杂.
对我来说,或者我认为
接口存在的目的就是让静态语言在实现业务的时候通过编译,好比你想加入帮会就得先去考公务员,进外企就得研究生毕业,你看动态语言就没有接口,所以有人当了n年主编才被发现毕业证是假的
大家认为呢.
问题补充
http://blog.csdn.net/chiangbt/archive/2008/01/15/2046015.aspx
这里有文章说的不错！
有道理 就是为了通过编译
解耦 ,或者说 间接, 或者说 封装变化
简单的说接口就是某项产品的[b]规范[/b]，这种产品可能有很多家厂商在做，每个厂商做出来的产品可能都不太一样，但是有了规范，不管你的产品怎么不一样，你肯定要符合这个规范，比方说自行车好了，都是两个轮子，每个厂商做出来的都一样，不可能是4个轮子的，那不是汽车了，但是你可以把自行车的轮子质量、颜色啊改改，这都是可以的。回过了，接口也就是这么一回事，就是个规范，来约束你做的东西，要求符合这个规范，为的就是好与这么多厂商做的兼容，换个零件等我不一定要去原厂家买，别的厂家的我也可以照样用。
显而易见,这个话题就不用讨论了吧?
实体耦合强于接口耦合，接口耦合强于签名耦合。
现在 支持delegate/类型推断/动态类型/GP 的语言里都几乎见不到接口语法了……
接口是契约， 用于约束调用双方的行为。
很多人会认为接口的意义在于顶替多重继承。Java没有c++那样多重继承的机制，但是却能够实现多个接口。然而接口和继承是完全不同的东西，接口没有能力代替多重继承，也没有这个义务。接口的作用，一言以蔽之，就是标志类的类别。把不同类型的类归于不同的接口，可以更好的管理他们。面向对象的精髓，我以为，是对对象的抽象，最能体现这一点的就是接口。
接口定义我认为
1 便于扩展
2 依赖注入
大家补充……
接口就是对用户的承诺，服务的契约，
内部你怎么实现用户不关心，我只要知道你的接口，我就可以调用接口中定义的方法，用soa的思想来说就是服务，
接口可以限制程序员的行为，要做什么，人家都给你定好了。
java的代理 拦截 反射
这些核心的东西
都是基于接口的 另一种是cglib
接口既然出了 就得有一套所谓的理论 说接口是一种契约规范是合理的。
但有些人的编程风格不同 种感觉接口是鸡肋
主要还是为了 java这套语言的底层实现上的可能而出现才有的东西
许多时候老大开发好接口下面的员工负责去实现也是很好的！
我估计你肯定是有所了解接口，但是不知道怎么去[b]用接口[/b]（是比较正确的用法）
我个人的一些看法：
如我你想用接口但是不知道适合不适合的时候你可以这样去考虑一下。你造的东西想不想通用，是不是在任何一个场合下都能用...譬如说[b]USB接口[/b]，如果这种场景的话你肯定得选择接口了... [b]一种规范多种不同场景实现必须选用接口[/b] 如果你要是只是写[b]一个实现[/b]的话那肯定在'额外'的写一个接口那就是没有必要的了。
希望我的个人看法对你有帮助...Good Luck...
接口简单的说就是一种规范,只要我们厂商规定这个规范,就能够很好的使用.例如又很多厂商来生产USB,而只要都按照了USB规范,哪么生产后的在什么样的USB接口都可以使用.在java应用程序中,我们用interface来定义接口.我们想用他,就可以在我们定义类中用implement关键字来实现他就可以.不过接口就是抽象的变体,不过接口只可以定义为static和final的成员变量.
大多数人认为，接口的意义在于顶替多重继承。众所周知Java没有c++那样多重继承的机制，但是却能够实作多个接口。其实这样做是很牵强的，接口和继承是完全不同的东西，接口没有能力代替多重继承，也没有这个义务。接口的作用，一言以蔽之，就是标志类的类别（type of class）。把不同类型的类归于不同的接口，可以更好的管理他们。OO的精髓，我以为，是对对象的抽象，最能体现这一点的就是接口。为什么我们讨论设计模式都只针对具备了抽象能力的语言（比如c++、java、c#等），就是因为设计模式所研究的，实际上就是如何合理的去抽象。（cowboy的名言是 “抽象就是抽去像的部分”，看似调侃，实乃至理）。
设计模式中最基础的是工厂模式（Factory），在我最近的一个很简单的应用中，我想尽量的让我的程序能够在多个数据库间移植，当然，这涉及很多问题，单是如何兼容不同DBMS的SQL就让人头痛。我们不妨先把问题简单化，只考虑如何连接不同的数据库。
假设我有很多个类，分别是Mysql.java、SQLServer.java、Oracle.java、DB2.java，他们分别连接不同的数据库，统一返回一个Connection对象，并且都有一个close方法，用于关闭连接。只需要针对你的DBMS，选择不同的类，就可以用了，但是我的用户他会使用什么数据库？我不知道，我希望的是尽量少的修改代码，就能满足他的需要。我可以抽象如下接口：
package org.bromon.test;
public interface DB
{
java.sql.Connection openDB(String url,String user,String password);
void close();
}
这个接口只定义两个方法，没有任何有实际意义的代码，具体的代码由实作这个接口的类来给出，比如Mysql.java：
Package org.bromon.test;
import java.sql.*;
public class Mysql implements DB
{
private String url=”jdbc:mysql:localhost:3306/test”;
private String user=”root”;
private String password=””;
private Connection conn;
public Connection openDB(url,user,password)
{
//连接数据库的代码
}
public void close()
{
//关闭数据库
}
}
类似的当然还有Oracle.java等等，接口DB给这些类归了个类，在应用程序中我们这样定义对象：
org.bromon.test.DB myDB;
使用myDB来操作数据库，就可以不用管实际上我所使用的是哪个类，这就是所谓的“开-闭”原则。但是问题在于接口是不能实例化的，myDB=new DB()，这样的代码是绝对错误的，我们只能myDB=new Mysql()或者myDB=new Oracle()。麻烦了，我还是需要指定具体实例化的是哪个类，用了接口跟没用一样。所以我们需要一个工厂：
package org.bromon.test;
public class DBFactory
{
public static DB Connection getConn()
{
Return(new Mysql());
}
}
所以实例化的代码变成：myDB=DBFactory.getConn()；
这就是23种模式中最基础的普通工厂(Factory)，工厂类负责具体实例化哪个类，而其他的程序逻辑都是针对DB这个接口进行操作，这就是“针对接口编程”。责任都被推卸给工厂类了，当然你也可以继续定义工厂接口，继续把责任上抛，这就演变成抽象工厂(Abstract Factory)。
整个过程中接口不负责任何具体操作，其他的程序要连接数据库的话，只需要构造一个DB对象就OK，而不管工厂类如何变化。这就是接口的意义----抽象。
继承的概念不用多说，很好理解。为什么要继承呢？因为你想重用代码？这绝对不是理由，继承的意义也在于抽象，而不是代码重用。如果对象A有一个run() 方法，对象B也想有这个方法，所以有人就Class B extends A。这是不经大脑的做法。如果在B中实例化一个A，调用A的Run()方法，是不是可以达到同样的目的？如下：
Class B
{
A a=new A();
a.run();
}
这就是利用类的聚合来重用代码，是委派模式的雏形，是GoF一贯倡导的做法。
那么继承的意义何在？其实这是历史原因造成的，最开始的OO语言只有继承，没有接口，所以只能以继承来实现抽象，请一定注意，继承的本意在于抽象，而非代码重用（虽然继承也有这个作用），这是很多Java烂书最严重的错误之一，它们所造成的阴影，我至今还没有完全摆脱，坏书害人啊，尤其是入门类的，流毒太大。什么时候应该使用继承？只在抽象类中使用，其他情况下尽量不使用。抽象类也是不能实例化的，它仅仅提供一个模版而已，这就很能说明问题。
软件开发的万恶之源，一是重复代码而不是重用代码，二是烂用继承，尤以c++程序员为甚。Java中取缔多重继承，目的就是制止烂用继承，实是非常明智的做法，不过很多人都不理解。Java能够更好的体现设计，这是让我入迷的原因之一。
强烈推荐你看看,java与模式 阎洪博士写的这本书
接口是抽象的，它描述的是抽象的行为，至于你怎样实现，那是你的事了，有点像一套规范或标准吧。好像说的还是很抽象。
我举个例子吧。比如你要做个论坛系统，你可以用接口定义这个论坛怎样怎样做，但是具体的实现没做。但是，通过这个接口及她定义的行为，我们知道这个论坛大概是什么样子的，也可以说接口描述了这个论坛的轮廓了。
有什么意义？我觉得得看情况，看你用在什么地方，怎么用啦。这没有什么具体的标准。