这可能是一个通用的OOP问题。我想在接口和抽象类的使用基础上做一个通用的比较。
什么时候需要使用接口,什么时候需要使用抽象类?
这可能是一个通用的OOP问题。我想在接口和抽象类的使用基础上做一个通用的比较。
什么时候需要使用接口,什么时候需要使用抽象类?
当前回答
对我来说,在很多情况下我会选择接口。但在某些情况下,我更喜欢抽象类。
OO中的类通常指的是实现。当我想强制一些实现细节到子程序时,我使用抽象类,否则我就使用接口。
当然,抽象类不仅在强制实现方面有用,而且在许多相关类之间共享一些特定的细节方面也有用。
其他回答
这是一个很难打的电话。
我可以给出一个提示:一个对象可以实现许多接口,而一个对象只能继承一个基类(在像c#这样的现代OO语言中,我知道c++有多个继承-但这不是不受欢迎吗?)
两者都是类定义的契约:
结论1:两种意图都是对象泛化
在定义抽象类时,它们也可以有默认实现。
结论2:区分存在于行为泛化设计中
在使用抽象类时,类只能从一个抽象类继承
结论3:抽象类在应用上存在局限性。它的意思是 行为概括的局限性。
最后结论-何时使用哪个:区分是在行为泛化层面
在类的行为设计中,如果功能在确定的类之间只是概念上的限制,换句话说,在确定的类之间是共享的,则使用抽象类。但如果功能比确定类更通用,或者我们可以/想要向其他类添加功能,则使用接口作为契约。
我的观点是:
接口基本上定义了一个契约,任何实现类都必须遵守(实现接口成员)。它不包含任何代码。
另一方面,抽象类可以包含代码,并且可能有一些标记为抽象的方法,继承类必须实现这些方法。
我很少使用抽象类的情况是,当我有一些默认功能时,继承类可能对重写不感兴趣,比如一个抽象基类,一些专门的类继承自它。
示例(非常基本的一个!):考虑一个名为Customer的基类,它具有抽象方法,如CalculatePayment(), CalculateRewardPoints()和一些非抽象方法,如GetName(), SavePaymentDetails()。
像RegularCustomer和GoldCustomer这样的专门的类将继承自Customer基类,并实现它们自己的CalculatePayment()和CalculateRewardPoints()方法逻辑,但是重用GetName()和SavePaymentDetails()方法。
您可以向抽象类(即非抽象方法)添加更多功能,而不会影响使用旧版本的子类。然而,向接口添加方法会影响实现它的所有类,因为它们现在需要实现新添加的接口成员。
具有所有抽象成员的抽象类类似于接口。
在Java中,您可以从一个(抽象)类继承来“提供”功能,并且可以实现许多接口来“确保”功能
简单的回答是:抽象类允许您创建子类可以实现或覆盖的功能。接口只允许您定义功能,而不能实现它。虽然一个类只能扩展一个抽象类,但它可以利用多个接口。