为什么要用接口而不用抽象类呢这是我去面试的题
为什么要用接口而不用抽象类呢这是我去面试的题

------解决方案--------------------
接口表达一个契约，表达系统和系统间的协议
属于业务层
而抽象类不过是提取公因式，简化代码而已

两相比较，接口较之抽象类更加抽象，是对外的，而抽象类则是实现层面，属于内部
------解决方案--------------------
具体情况具体考虑 不是所有的都要用接口而不用抽象类
接口用来定义行为，实现接口的类可以实现这些行为，从而使定义与实现分离
抽象类作为公共的父类，继承它的子类能复用或扩展父类的某些行为或属性
------解决方案--------------------
在十年前、“四人帮”发表“设计模式”时代、微软的COM正在推广的时代、VB5时代、OO概念开始深入人心时代，盛行上面那种说法。道理并不是真正OO设计意义上的，而是纯粹编程的，是说：继承结构会把父类里边坏的流程带给子类，而interface不会。废话，什么也不做仅仅规定一个接口的当让不会。实际上那时候的这些原始的流派都是教丝毫不理解、从骨子里反对OOAD的人去使用对象、OOPL工具，特别是“设计模式”是处在OOPL刚出现的时期，拿着OOPL的形式去演绎结构化的设计，所以才会看到那好二十几个像旧式老太太裹脚布一样又丑又难理清的模式。

基本上，如果今天有人能翻出最近5年写的软件工程著作清晰的证明这个规则，可以说这个著作一定是照抄十年前的理论的。但是OO需要好几年才能会用来进行软件动态模型设计（会用“对象”概念搞个静态模型的人也不少），及时有5年开发经验，用OOPL但是骨子里是结构化的人仍然占大多数。
------解决方案--------------------
刚刚胡思乱想的，

抽象类就像基因遗传，

而接口则像基因突变。

个人异想天开，切莫当真！
------解决方案--------------------
问题不是这么说的吧, 接口有接口的用处, 虚类有虚类的用处.

java里搞一下spring, .net里搞一下castle ioc, 就会明白, 什么时候用接口, 什么时候用虚类; 

也可以先看看jdk和.netframework, 看看他们的接口和虚类是什么时候用的
------解决方案--------------------
接口 同时适用与引用类型和值类型
值类型使用接口，在放入集合类型中时，可以减少值类型的拆箱操作
接口 可以实现多继承，可以被多个类型重用

抽象类 更具体聚集的描述了一种抽象 
比如 鸟 是被抽象 
而 I飞 则定义为接口较好，因为 鸟可以实现该接口，飞机也可以实现改接口。
如果要 操作 所有可以飞的对象 那么 用I飞作为参数 很好 而不是 为每个可以飞的抽象类定义一个重载 或者 直接 传递 “动物” 或者“物体”或者object
这样又把内部其他数据暴露了。
------解决方案--------------------

看一堆人布龙门阵～～，顺便说说，此题出的太烂～
------解决方案--------------------
自己考虑了一下
类继承--->子类完全继承父类特点
抽象类继承--->继承时抽象的部分不同的子类可以有不同的实现
接口继承--->所有成员在子类都可以有不同的实现

至于为什么要用接口而不是抽象类
这要看二者适用的情况
当个性大于共性时,适合接口,如鸟和飞机,适合抽象出一个飞的接口
当共性大于个性时,适合抽象类,如老鹰和麻雀,适合抽象出一个鸟的父类
另外接口可以实现多重继承,这也是一个特点
------解决方案--------------------
此题出的太烂，只要知道各自的特点和适用情况就成了

没啥是一定要用啥，一定不用啥的。所有的东东都是根据应用场景而变的。

问啥你就是男的，因为当时当地x遇上了y，而不是x遇上了x。
------解决方案--------------------
此题出的太烂，只要知道各自的特点和适用情况就成了

没啥是一定要用啥，一定不用啥的。所有的东东都是根据应用场景而变的。

问啥你就是男的，因为当时当地x遇上了y，而不是x遇上了x。