面向对象：接口继承还是类继承？

面向对 象：接口 继 承 还 是 类继 承

我们项目开发中，为了实现各种各样的需求，需要设计封装功能。其中方法的调用是基于接口好呢还是类好呢？

比如我们有一个共通功能。其中有一个初始化处理根据企业不同，初始化的处理也不同。但是并非所有企业都必要做初始化处理。

方案1：接口（Interface）继承

public interface　共通处 理 {

public void init();

}

方案2：类继 承（虚 类 ，虚函数）

public abstract class 共通处 理 {

public abstract void init();

}

方案3：类继承（虚类，非虚函数）

public abstract class 共通处 理 {

public void init() {

do nothing;

}

}

方案4：类继承（非虚类，非虚函数）

public class 共通处 理 {

public void init() {

do nothing;

}

}

先看接口的优缺点:

接口优 点：

--不必知道其使用对 象的具体所属 类

--一个对 象可以很容易地被（ 实现 了相同接口的）的另一个 对 象所替 换

--对 象 间 的 连 接不必硬 绑 定（hardwire）到一个具体 类 的 对 象上，因此增加了灵活性

--松散藕合（loosens coupling）

--增加了重用的可能性

--提高了（对 象） 组 合的机率，因 为 被包含 对 象可以是任何 实现 了一个指定接口的 类

接口 缺点： 增加了复 杂度

接口，虚函数，虚类都是必须要在子类中实现的。

就上面的需求来说，上面几个方案的分析如下：

方案1：具有接口的优点，但是每个企 业都必须要写一个自己的实现类。还有就是接口如果扩展的话，所有企业的实现类都需要修改（维护成本加大）

方案2：和方案1的一样， 每个企 业都必须要写一个自己的实现类。还有就是超类如果扩展的话，所有企业的子类都需要修改（维护成本加大）

方案3：和方案1的一样， 每个企 业都必须要写一个自己的实现类。还有就是超类如果扩展的话，所有企业的子类不需要 强行要求 修改。

方案4：不要求所有企业都要写一个子类，满足需求。即使超类扩展，也不 强行要求去修改子 类。

方案4在阶段性开发中是比较好的一种方案，因为开发公司可能只修改一部分企业的功能，而没有权限去修改其他企业的功能。

究竟是接口继承还是类继承，主要还是要看功能需求，系统架构和开发性质。