在Java中使用抽象類時的編碼風格

在不是所有方法都將被實現的場景中從基類繼承時，最好是將空方法放入基類中，以便不需要那些子類方法完全可以忽略它，而其他類必須覆蓋的方法，如果他們想實現它...例如：在Java中使用抽象類時的編碼風格

基類：

public void myMethod() { 
}

子類，沒有實現：

<nothing!>

或者更好的辦法是讓基類變得更清潔，並且只是放入一個抽象方法，並強制子類充實一個空白的方法，如果它沒有實現該方法？

基類：

public abstract void myMethod();

子類，沒有實現：

public void myMethod() { 
}

來源

2012-12-12 fig

您可以使用接口代替 – Smit

其他地方的抽象類具有執行某些操作的方法。目前還沒有選擇將其轉換爲接口。我應該在問題中注意到我期待很多「不使用繼承」的答案！ :-) – fig

我會採用第二種方法，並讓子類在這些方法中實際引發異常。這將確保不必要的方法不在不應該在的子類上調用。 – ryadavilli

這取決於你，它取決於具體情況。

當你有一個抽象類，並且你想要擴展它來實現該方法的類時（因爲抽象父類使用抽象方法 - 它可能類似於print()）），你可以使用抽象方法。它與接口的方法類似，但通常用於不同的場景。但我會用接口在大多數情況下...

我會用抽象方法只有在情況下myMethod()做不同的事情在每個擴展抽象父類......否則，如果myMethod()通常不相同事情和一個或兩個類需要重寫它，我將使用第一個解決方案。

也看看模板方法模式。我不知道你是哪種情況，所以我不能以確切的方式回答這個問題。

來源

2012-12-12 17:27:52 user219882

在抽象類的differenct是，你可以，但絕不能覆蓋該功能。

因此public void nothing() {}可以被覆蓋並且public abstract void nothing2();必須被覆蓋。

來源

2012-12-12 17:23:46 rekire

@MikeDeck謝謝我錯過了這個。 – rekire

這是您的設計決定。如果你想強迫你的開發人員重寫myMethod並開發邏輯。你應該去抽象類。

來源

2012-12-12 17:25:20 Suranga

編碼風格取決於您，取決於您的要求，並且所有內容都有自己的優點和缺點。

在抽象類的情況下，沒有必要只放抽象的方法。我會建議你，最好使用接口。

來源

2012-12-12 17:25:22

兩者都不是最優雅的解決方案，儘管兩者都可以完成工作。使用設計模式策略設計模式http://www.newthinktank.com/2012/08/strategy-design-pattern-tutorial/

來源

2012-12-12 17:26:51 CodeDreamer

只要有可能，你應該

寧可抽象類接口

因爲接口不允許包含方法的實現，有所謂抽象*接口*，這是一個組合這兩種技術：在這種情況下，接口定義了類型，而抽象類提供了一個骨架實現。
一個例子是收集框架提供骨骼implemantations：AbstractCollection, AbstractList, AbstractSet and AbstractMap.

更多信息見喬希布洛赫，有效的Java第二版，第18項

來源

2012-12-12 17:40:28 AlexWien

我認爲它歸結爲是否存在myMethod的一個有意義的默認實現（）。如果存在，則將其放入基類中，如果子類需要不同的東西，則僅覆蓋子類。

如果沒有有意義的默認值，並且實際上每個非抽象子類都應該實現方法本身或從中間類繼承實現，那麼在基類中提供假實現是一個非常糟糕的主意。它將編譯器可能檢測到的錯誤轉換爲只能通過測試找到的錯誤。

在某些情況下需要考慮的一個選擇是提供一個引發UnsupportedOperationException的默認實現。

來源

2012-12-12 17:47:50

Java本身在某些類中提供了此功能[請參閱此處的示例]（http://docs.oracle.com/javase/6/docs/api/java/util/List.html#add%28E%29）。這允許使用'List'，例如'ImmutableList implements Lists ' – durron597

這是一個很好的觀點。但我可能應該指出，通常在這些情況下調用未實現的方法並不是一個例外，它只是無所作爲。例如。當子彈擊中裝甲車輛時，該方法不需要做任何事情，但是當他們撞上汽車時會發生什麼。 – fig

在Java中使用抽象類時的編碼風格

回答

相關問題