这可能是一个通用的OOP问题。我想在接口和抽象类的使用基础上做一个通用的比较。

什么时候需要使用接口,什么时候需要使用抽象类?


当前回答

两者都是类定义的契约:

结论1:两种意图都是对象泛化

在定义抽象类时,它们也可以有默认实现。

结论2:区分存在于行为泛化设计中

在使用抽象类时,类只能从一个抽象类继承

结论3:抽象类在应用上存在局限性。它的意思是 行为概括的局限性。

最后结论-何时使用哪个:区分是在行为泛化层面

在类的行为设计中,如果功能在确定的类之间只是概念上的限制,换句话说,在确定的类之间是共享的,则使用抽象类。但如果功能比确定类更通用,或者我们可以/想要向其他类添加功能,则使用接口作为契约。

其他回答

车辆包括汽车、坦克、飞机、手推车等。

抽象类Vehicle可以有子类,如car、tank、plane、cart等。

public abstract Vehicle {...}

public Car extends Vehicle {...}

public Tank extends Vehicle {...}

那么,什么是可移动的?几乎一切! 然后

石头,蛋糕,汽车,行星,星系,甚至你都是可移动的!

它们中的大多数也是可观察的!

什么是可吃的?这是一款名为《美味星球》的游戏。 然后

石头,汽车,行星,星系,甚至时间!

public interface Movable {...}
public interface Observable {...}
public interface Eatable {...}

public class Stone implements Movable, Eatable, Observable {...}

public class Time implements Eatable, Observable {...}

public class Stupidity implements Observable {...}

终于!

public class ChocolateCar extends Vehicle implements Eatable {...}

1.如果您正在创建为不相关的类提供公共功能的东西,请使用接口。

2.如果您正在为层次结构中密切相关的对象创建一些东西,请使用抽象类。

我为此写了一篇文章:

抽象类和接口

总结:

当我们谈论抽象类时,我们是在定义对象类型的特征;指定对象是什么。

当我们谈论接口和定义我们承诺提供的功能时,我们谈论的是建立一个关于对象可以做什么的契约。

抽象类可以有实现。

接口没有实现,它只是定义了一种契约。

也可能存在一些依赖于语言的差异:例如c#没有多重继承,但在一个类中可以实现多个接口。

什么时候选择抽象类而不是接口?

如果计划在程序/项目的整个生命周期中更新基类,最好允许基类是一个抽象类 如果有人试图为层次结构中密切相关的对象构建主干,那么使用抽象类是非常有益的

什么时候选择接口而不是抽象类?

如果不需要处理大量的层次结构类型的框架,那么接口将是一个很好的选择 因为抽象类不支持多重继承(菱形问题),所以接口可以挽救局面