接口，抽象类的使用

这位说的太偏激了。。。。。
现在面向接口的编程不是很好很强大么，大家评价都蛮高的。
如果都用多继承而且没有interface的话，代码的黏合度不是很很高么？
这样对代码的简洁度、解耦合好像都是有些问题的。。

不知道说的对不对

我认为抽象类跟接口负责的功能是一样的！制定一些接口规范！其它的子类必须实现它们定义的未实现的方法！接口跟抽象类不同的地方是抽象类可以有一些方法里边有代码！当有一些代码是几个子类都有的时候就可以抽象到抽象类！如果没有公用的代码就用接口！就这么简单！

忍不住要晒一下观点：interface是约定的contract，对外部调用者的承诺，设计精髓的体现(对象的职责)。良好的interfacer设计可以保证边界清晰、程序的稳定、真正的松耦合。
而Abstract Class是对内部实现的一个基础，最多只是对内部实现提供一些重用而已。或者说，interface关注的是外部的使用者，而Abstract Class是对内的。
并且在复杂的环境下，继承会带来许多副作用。继承层次多，或者扩展点过多时，增加一个子类绝对是一个灾难：需要了解大量父类的内部实现细节，例如经典的Template Method、Strategy等模式。组合应该是更好的实现方式。

我的理解，面向对象更重要的是，保持整体结构的清晰、模块的松耦合。而不是小范围的重用问题。Procedure/Function的重用也可以很好，甚至更简单、容易。

同意楼上所说的:interface关注的是外部的使用者，而Abstract Class是对内的。

接口是定义了一些规格(规则),这些规格是对外的.
抽象类则是对内部变化的一种封装.

从面向对象分析与设计的角度来说：
abstract class表示“is-a”的关系，即父类与继承类本质上一致的；
对于interface，并不要求interface的实现者和interface定义在概念本质上是一致的， 只表示一种契约关系，可以将interface看成“like-a”或者“has-a”的关系（这种说法不是很准确）。

举例来说：电视机、收音机同属电器，具有打开，关闭，调台的方法；同时电视机、收音机都有遥控器（收音机带遥控器的好像不多！）。

类结构如下：
abstract class 电器{
       public void 打开（）{}
       public void 关闭（）{}
       public void 调台（）{}
}

interface 遥控器{
      void 遥控(){}
}

class  电视机 extends 电器 implements 遥控器{
       //重写方法，略
}
class  收音机 extends 电器 implements 遥控器{
       //重写方法，略
}

我觉得抽象内和继承相关，比如拿文档类来说，都有title，time属性，并且getTime,setTime都是相同方法，就用抽象类处理；
接口运用比较广泛，大多为了解耦，使高层完全不用知道子类的变换和约定的一个协约，这样高层就不再依赖底层。灵活调用，当底层发生变化时也完全不用通知高层。

楼主需要的接口可以简化为
Iterable<YourDataType>

一般会分离实现的。不会abstract class AbstractFileDataParser implements IDataParser。而是采用注入的方式。比较好。 典型的策略或者模板设计模式。

接口做名词
抽象类做动词

框架主要是抽象类+工厂。

我觉得用继承是为了达到复用，用接口是为了达到灵活（松耦合），权衡二者的利弊之后再决定