抽象類和接口在一起？

Question

我有一段代碼，其中一些類正在實現一個接口。

這感覺是正確的，但是在兒童班中有一點重復 - 即3種方法。

所以這是尖叫着使用抽象類。

我的問題是，在以下情況下使用抽象類和接口是否有任何缺點：

1. 抽象類實現接口和子類來擴展抽象類
2. 子類擴展抽象類並實現接口

要么

抽象類和接口是否應該像這樣一起使用？

Answer 1

將這兩者結合使用是完全正常的。 考慮例如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 { }

此外，我可以看到一個參數做這種方式，具體地，它消除了抽象類和接口之間的耦合。 如果您有其他類的功能性需求Base規定，但並不需要實現該接口，您可以靈活地做到這一點。

還有第三種選擇：組合。 根本沒有抽象類，而是實現接口的多個具體類在其實現中使用公共幫助器類：

class Helper {
    /* ...shared methods... */
}

class Concrete1 implements TheInterface {
    /* ...uses instance of Helper */
}

class Concrete1 implements TheInterface {
    /* ...uses instance of Helper */
}

這具有相同的靈活性，另一種形式。

Answer 2

我不認為有這樣的經驗法則。 在設計時嘗試並遵循SOLID原則來確定您所做的事情是好還是壞。 你可以在這里找到這些原則。 在這種特殊情況下，我認為你應該確保你遵守“開放 - 關閉原則”。

Answer 3

我個人更喜歡抽象類是其他類的背景的聲明，所以如果其他三個類有共同點，那么它們的共同祖先，即僅為這三個其他類創建的抽象類，也應該提供來自接口的代碼。 這將使抽象類“完整”（以其方式）提供三個類共享的所有這些屬性和方法。

但是，如果所有這些都實現相同的接口，它最終沒有區別。 在我看來，使抽象類給出一切常見的東西是一種更清晰的方式。 然后通過僅查看不同的類來比較類更容易。