我有時最終得到一個類層次結構，其中我有一個抽象基類，它具有一些常用功能，還有一些實現類落入兩個（很少更多）組中，我想在某些情況下對其進行不同處理。一個例子是一個抽象樹節點類和不同的分支和葉子實現，我想在某個時刻區分分支和葉子。在類層次結構的中間是否有空類？
這些中間類則僅用於「是一個」流量控制語句，它們不包含任何代碼，雖然我曾在那裏他們「長大」了一些代碼後的情況。
這對你來說看起來很臭嗎？在我的樹例子中，另一種方法是將基本類的抽象方法添加到中間類中，然後在中間類上實現這些方法，但對我來說這似乎沒有什麼更好，除非我想要一次可能是多件事的類。
一般情況下，空類是一個代碼味道。
我同意你的isLeaf或isBranch方法是正確的選擇。 他們添加有關對象的信息，這很有幫助。 （這是因爲，在超類中，你不能表達該子類是「葉或分支」）。
的兩種方法具有相反的結果可能也被認爲是代碼重複。
你可以只使用一個......但我會建議返回一個枚舉值LEAF或BRANCH。
是的，深層繼承層次結構無論如何都是代碼異味。
不包含任何代碼，絕對是一個代碼味道....類
對我來說，在流量控制中使用「is-a」測試就像使用開關/外殼一樣臭。在一個很好的OO設計中，都不是必需的。
我同意，這是更關鍵的問題。 –
+1我同意。雖然這種類型的非OO設計可以在重構之前暫時使用，或者如果不同的類應該有一個方面（分離職責），也可以使用這種類型的非OO設計。 **尋找類層次結構的確切平衡是一個困難的和演變的過程**通常。 – KLE
我同意100％。我不能告訴你我在switch語句中有多少參數不是很好的OO。 –
是的，絕對是一個代碼味道 - 除非你準備的代碼寫進去不編碼這些空類。想想YAGNI（你不需要它） - 不要這樣做，除非你已經需要它。
而且，你有沒有考慮的情況，其中這些類只有在那裏提供抽象方法，或將它們組合中的方法或屬性方面基於能力？
如果是這樣的話，也許你真正需要的是接口，而不是額外的抽象類？
感謝您的其他建議。我談論的情況下，接口不會幫助我，但。 –
+1好曝光自己:-) – KLE
@KLE :-)恩，謝謝你成爲我的觀衆。我幾乎是在整個職業生涯中爲自己工作，有時很難獲得外部意見。 –
@Hanno好吧，你做得很好，別擔心。儘管繼續。我對你的158個問題印象深刻！ ;-) – KLE