这可能是一个通用的OOP问题。我想在接口和抽象类的使用基础上做一个通用的比较。
什么时候需要使用接口,什么时候需要使用抽象类?
这可能是一个通用的OOP问题。我想在接口和抽象类的使用基础上做一个通用的比较。
什么时候需要使用接口,什么时候需要使用抽象类?
当前回答
抽象类可以具有共享的状态或功能。接口只是提供状态或功能的承诺。一个好的抽象类可以减少必须重写的代码量,因为它的功能或状态可以共享。接口没有可共享的已定义信息
其他回答
什么时候选择抽象类而不是接口?
如果计划在程序/项目的整个生命周期中更新基类,最好允许基类是一个抽象类 如果有人试图为层次结构中密切相关的对象构建主干,那么使用抽象类是非常有益的
什么时候选择接口而不是抽象类?
如果不需要处理大量的层次结构类型的框架,那么接口将是一个很好的选择 因为抽象类不支持多重继承(菱形问题),所以接口可以挽救局面
抽象类可以具有共享的状态或功能。接口只是提供状态或功能的承诺。一个好的抽象类可以减少必须重写的代码量,因为它的功能或状态可以共享。接口没有可共享的已定义信息
抽象类可以有实现。
接口没有实现,它只是定义了一种契约。
也可能存在一些依赖于语言的差异:例如c#没有多重继承,但在一个类中可以实现多个接口。
车辆包括汽车、坦克、飞机、手推车等。
抽象类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 {...}
基本的经验法则是:对于“名词”使用抽象类,对于“动词”使用接口
例如:car是一个抽象类和驱动器,我们可以让它成为一个接口。