接口和抽象类的区别？
也工作了很长时间了，可是一直搞不太懂接口和抽象类的区别和联系到底是怎么回事，面试的时候感觉好多公司都爱问这个问题，请大牛们给分析一下。 --------------------编程问答-------------------- 这内容，网上一搜一大把。 --------------------编程问答-------------------- 网上搜吧 简单点 你实现了一个接口 就必须要实现接口里面的所有方法对于抽象类 你就不必要这样
在我们生活的理解 可能就是你去买包装的产品跟散装的产品的区别 --------------------编程问答-------------------- 根本区别 抽象类可以有实现体。 --------------------编程问答-------------------- 这些个问题虽说是基础，但是也要实际应用下才可以完全理解清楚呢~~ --------------------编程问答-------------------- 接口相当于规范，抽象类相当于半成品 --------------------编程问答-------------------- 5L比较认同 --------------------编程问答-------------------- 接口要实现，抽象类要继承。
实现类里的方法必须全部在接口中定义，但实现类不一定要实现接口中的所有方法。
抽象类里的所有方法必须在子类中实现，但子类内可增加其他方法，而不需要修改抽象类。 --------------------编程问答-------------------- http://bbs.csdn.net/topics/330148155 --------------------编程问答--------------------
我面试的时候也专门准备了这个问题。
其实也不难，
虽然定义不准确，也可以这么理解
抽象类就等于普通类+接口的功能。
抽象类是可以实现接口的。 --------------------编程问答-------------------- 窃以为：
接口是can do something，是种契约，仅代表，实现它的类的实例，（除了出Exception的情况）一定能完成某（些）个任务。但是具体如何完成，你不知道，你也不需要知道也不应该关心
抽象类是is something/has some properties。抽象类当然也能完成一些任务，但是，他除了完成这（些）个任务以外，还被强制规定死了，有些其他的属性，而且，很多时候，想换个方式完成这（些）个任务，因为已经在“体制内”，实在是很难很难。
举个例子（下面说道的概念，仅在这个例子的范围内有效，换个应用，可能完全颠覆）
“能飞的”是个接口，所有实现这个接口的类的实例，除了特例，都能飞起来
public interface Flyable {
public void fly();
}而“鸟”这个概念，显然，除了能飞，还有些固定的属性，比如翅膀，喙什么的：
public abstract class Bird // 上面还可能有Animal之类的父类，这里省略
implements Flyable // 这里可能还有其他接口，比如“会吃东西”，“会叫”...
{
private Wing wings; // 翅膀
private Beak beak; // 喙
// 其他是鸟都会有的“属性”。当然有些属性，应当是在Animal这个层级的
public void fly() {
wings.vibrate(); // 默认的实现方式，扇动翅膀
}
// 其他功能
}
public class Sparrow extends Bird {
// 麻雀自己的一些特性
}
public abstract class WaterBird implements Swimmable {
// 水禽都能游泳，在这里“能游泳”也是接口，而水禽成了“抽象类”
// 水禽的一些特性
}
public class Swan extends WaterBird {
// 天鹅自己的一些特性
public void fly() {
if (water.getLength() < 100) {
throw new FieldTooSmallException(); // 天鹅需要长距离助跑
}
runOnTheWater();
wing.vibrate();
}
}
// 少数的例外
public class Ostrich extends Bird {
public void fly() {
throw new UnsupportedOperationException("鸵鸟不会飞！");
}
}
回到Flyable这个接口，不是所有Flyable都是Bird，至少还有
public abstract class Insect // 上面还可能有Animal之类的父类，这里省略
implements Flyable // 这里可能还有其他接口，比如“会吃东西”，“会叫”...
private Wing wings; // 翅膀
// 头胸腹，6条腿...
}
// 蝙蝠是哺乳动物，哺乳动物不能飞，但是它能，刚好和鸵鸟相反
public class Bat extends Mammal implements Flyable // 可能还有其他接口
{
// 蝙蝠的特性
public void fly() {
// 蝙蝠那个就不能叫翅膀了...
}
}
public abstract class Aircraft implements Flyable // 可能还有其他父类、接口，比如是“机器”（类），“能加油”（接口）
{
....
}
但愿上面的例子，能够让你在决定用接口还是抽象类的时候有所助益。
实在想不明白，优先定义接口，用到其功能的地方，一律使用接口类型。然后，再提供一个通用的“抽象类”，提供一系列“模板方法”，实现这个接口的功能。
--------------------编程问答-------------------- 忘了一句。如果把刚才“能飞”这个概念，定义为抽象类Fly（不是苍蝇
）你会发现，要实现我刚才说的那些，让这些东西，都出现在天上，几乎是不可能的。 --------------------编程问答-------------------- 抽象类与接口的两大区别：
（1）在抽象类中可以为部分方法提供默认的实现，从而避免在子类中重复实现它们，提高了代码的可重用性，这是抽象类的优势所在；而接口只能包含抽象方法。
在抽象类中允许加入具体的方法（非抽象方法），因此口占抽象类的功能，即向抽象类中添加一个具体的方法不会对其子类造成影响，但是对于接口，一旦接口被公布，就必须非常稳定，因为随意在接口中添加抽象方法，会影响到实现类，这些实现类要么实现新增的抽想方法，要么声明为抽象类。
（2）一个类只能继承一个直接的父类，这个父类有可能是抽象类；但一个类可以实现多个接口，这是接口的优势所在。 --------------------编程问答-------------------- 接口是用来实现的，抽象实际中很少用到 --------------------编程问答-------------------- 一般都是先定义接口，然后用一个抽象类实现接口的部分方法，再从这个抽象类派生出具体的实现类。 --------------------编程问答-------------------- 接口比抽象类灵活，其实说白了就是java不支持多继承，用接口这种多实现的形式弥补了一下 --------------------编程问答-------------------- 类和接口都是对对象的抽象描述。
而类已经描述了对象的属性和行为了，而接口一般用于描述行为而已。
类原本完全可以代替接口的工作，而许多语言的作者为了体现接口的精华，硬生生地限制类不能多继承 而接口可以。
我认为，
如果要类，就不需要接口，行为和属性类全包了，像C++
如果要接口，就干脆不要类，直接接口+结构就行，接口负责对象的行为描述，结构负责对象的属性描述。 --------------------编程问答-------------------- 除 --------------------编程问答--------------------
这个好像是head first 设计模式中的 策略设计模式，多用组合，少用继承，用接口会更加灵活，不过还是哟啊具体问题具体分析了。
--------------------编程问答-------------------- 面向接口编程，比如java sql包下面很多是接口，它本身并不提供实现，而是由你的数据库去实现，你要回想用我的这个类，那么就必须按照我的定义来实现。简单说就是规范，这些都是一流公司做的哟。二流，三流公司只能跟在他们后面。 --------------------编程问答-------------------- 顶tank,
例子恰当+条理清晰。
haha~~~
time to close your post, OP. --------------------编程问答-------------------- 接口是抽象类的一种特例，即接口里面全部都是抽象方法。而抽象类里面可以定义抽象方法，也可以定义具体的方法。接口要求实现，抽象类是继承 --------------------编程问答--------------------
接口是特殊的抽象类，详见我的日志：http://blog.csdn.net/fonyer/article/details/8961268
补充：Java , Java EE
