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

Question

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

Answer 1

一般我写代码的时候，
先用接口确定系统行为，然后用Mock类进行对接口的实现
在这个时候根本就没抽象类什么事情
然后将具体化，则出现很多很多具体类，出现很多重复代码
将其提炼出抽象类简化代码所以说这两个东西是各有用处，合适的时候用合适的东西may i helps

Answer 2

这就好像是问你“为什么要用c而不用c++呢？”。另外这个问题有个噱头，就是加上了“抽象二字”。90年代中期，当OOPL刚刚盛行的时候，还没有java、.net，那时候大多数不了解OO的程序员很习惯“用组合而不要用继承”的这种说法。现在，多看看类似.net famework的源代码，扪心自问，.net framework中难道是“只用接口而不用类型了吗”？实际情况摆在眼前，到底是类型多还是接口多？如果不是为了多重继承还需要这么多接口吗？

Answer 3

在十年前、“四人帮”发表“设计模式”时代、微软的COM正在推广的时代、VB5时代、OO概念开始深入人心时代，盛行上面那种说法。道理并不是真正OO设计意义上的，而是纯粹编程的，是说：继承结构会把父类里边坏的流程带给子类，而interface不会。废话，什么也不做仅仅规定一个接口的当让不会。实际上那时候的这些原始的流派都是教丝毫不理解、从骨子里反对OOAD的人去使用对象、OOPL工具，特别是“设计模式”是处在OOPL刚出现的时期，拿着OOPL的形式去演绎结构化的设计，所以才会看到那好二十几个像旧式老太太裹脚布一样又丑又难理清的模式。基本上，如果今天有人能翻出最近5年写的软件工程著作清晰的证明这个规则，可以说这个著作一定是照抄十年前的理论的。但是OO需要好几年才能会用来进行软件动态模型设计（会用“对象”概念搞个静态模型的人也不少），及时有5年开发经验，用OOPL但是骨子里是结构化的人仍然占大多数。

Answer 4

面向对象有很多工程化的好办法清晰地定义继承、组合时的协议。java、.net的语法还是太简单了。如果按照那种看法，越是低级的东西越应该用来取代高级的协议，取代语言编译器的进一步开发，因为更低级原始就说成更”万能“，那么面向人的开发语言（而不是面向机器的）还有什么意思呢。

Answer 5

问题不是这么说的吧, 接口有接口的用处, 虚类有虚类的用处.java里搞一下spring, .net里搞一下castle ioc, 就会明白, 什么时候用接口, 什么时候用虚类; 也可以先看看jdk和.netframework, 看看他们的接口和虚类是什么时候用的

Answer 6

接口 同时适用与引用类型和值类型
值类型使用接口，在放入集合类型中时，可以减少值类型的拆箱操作
接口 可以实现多继承，可以被多个类型重用抽象类 更具体聚集的描述了一种抽象 
比如 鸟 是被抽象 
而 I飞 则定义为接口较好，因为 鸟可以实现该接口，飞机也可以实现改接口。
如果要 操作 所有可以飞的对象 那么 用I飞作为参数 很好 而不是 为每个可以飞的抽象类定义一个重载 或者 直接 传递 “动物” 或者“物体”或者object
这样又把内部其他数据暴露了。

Answer 7

自己考虑了一下
类继承--->子类完全继承父类特点
抽象类继承--->继承时抽象的部分不同的子类可以有不同的实现
接口继承--->所有成员在子类都可以有不同的实现至于为什么要用接口而不是抽象类
这要看二者适用的情况
当个性大于共性时,适合接口,如鸟和飞机,适合抽象出一个飞的接口
当共性大于个性时,适合抽象类,如老鹰和麻雀,适合抽象出一个鸟的父类
另外接口可以实现多重继承,这也是一个特点

Answer 8

此题出的太烂，只要知道各自的特点和适用情况就成了没啥是一定要用啥，一定不用啥的。所有的东东都是根据应用场景而变的。问啥你就是男的，因为当时当地x遇上了y，而不是x遇上了x。

Answer 9

此题出的太烂，只要知道各自的特点和适用情况就成了没啥是一定要用啥，一定不用啥的。所有的东东都是根据应用场景而变的。问啥你就是男的，因为当时当地x遇上了y，而不是x遇上了x。