我有一段代码,其中一些类正在实现一个接口。
感觉是正确的,但是儿童班级之间存在一些重复 - 即3种方法。
所以这是在尖叫着使用抽象类。
我的问题是,在以下情况下使用抽象类和接口是否有任何缺点:
或者
抽象类和接口是否应该像这样一起使用?
答案 0 :(得分:19)
将这两者结合使用是完全正常的。例如,考虑在JDK中AbstractList
(实施List
)和AbstractMap
(实施Map
)。
我的下意识反应是让抽象类实现接口,然后从中派生具体类:
abstract class Base implements TheInterface {
/* ...shared methods... */
}
class Concrete1 extends Base { }
class Concrete1 extends Base { }
但你提出另一种可能性的问题让我思考,而且我不能看到很多反对这样做的论点:
abstract class Base {
/* ...shared methods... */
}
class Concrete1 extends Base implements TheInterface { }
class Concrete1 extends Base implements TheInterface { }
此外,我可以看到一个参数 for 这样做,特别是它删除了抽象类和接口之间的耦合。如果您有另一个类需要Base
提供的功能但不需要实现该接口,那么您可以灵活地执行此操作。
还有第三种选择:组合。您根本不可能有一个抽象类,而是拥有多个具体类来实现接口在其实现中使用一个公共帮助器类:
class Helper {
/* ...shared methods... */
}
class Concrete1 implements TheInterface {
/* ...uses instance of Helper */
}
class Concrete1 implements TheInterface {
/* ...uses instance of Helper */
}
这具有相同的灵活性,另一种形式。
答案 1 :(得分:1)
我不认为有这样的经验法则。在设计时尝试并遵循SOLID原则来确定您所做的事情是好还是坏。您可以在here上找到这些原则。在这种特殊情况下,我认为你应该确保你遵守“开放式原则”。
答案 2 :(得分:0)
我个人更喜欢抽象类是其他类的背景的声明,所以如果其他三个类有共同点,那么它们的共同祖先,即仅为这三个其他类创建的抽象类,也应提供来自接口的代码。这将使抽象类“完整”(以其方式)提供三个类共享的所有这些属性和方法。
然而,如果所有这些都实现相同的接口,它最终没有区别。在我看来,使抽象类给出一切常见的东西是一种更清晰的方式。然后通过仅查看不同的类来比较类更容易。