很多權威人士，包括OO粉絲，都不喜歡“繼承”，但是它讓我將一個通用行為調整到特定行為時更有用和簡單，只是它被誤用了，像很多技術一樣，需要學會如何好好地用它。

眾說紛紜：

1. 我預設使用組合，並且如果在重複幾次之後有意義時才使用繼承。

2. 不幸的是，繼承通常用於非業務範圍，而不是使用在領域邏輯上。一個很好的例子是一些Web框架需要擴充套件控制器或模型類的方式。繼承具有良好的用例，但它不應該是預設選項。

3. 對不起，這就像是說廚師應該預設使用鈍刀，因為他們可能會用鋒利的刀削減自己。

4. 當我需要一切都符合相同的契約或者部分例項化類時，我喜歡使用繼承。繼承的核心問題是：它只是眾多類關係中的一個，但它被提升為核心語法

5. 我謙卑地建議你使用繼承，會比“普通開發者”好幾個數量級。預設值很重要。OOP允許預設繼承，這導致在實際幫助的少數情況下更多的病態耦合。

6. 當你看到一個實現12個介面的類，每個介面只有1個方法時，你可能會開始認為組合不是銀彈，繼承也不是。一個設計良好的解決方案使用兩者。

7. 關於繼承的最危險的事情，它使得調整通用行為變得簡單。易於實施，但維護成本不明確（特別是如果我們在層次結構中定期進行這些型別的更改），會分佈在多個檔案中。

8. 我對使用繼承，介面隔離結合應用DDD模式實現的模型有很好的經驗。例如，使用子域的繼承使關係變得清晰（非常明確）並且非常有用。

9.不幸的是，函式性程式設計現在很流行，人們不明白這些東西只是工具。繼承不僅僅是OO的東西。有些人認為。例如，在Clojure中有一些簡潔的機制。

10. 繼承意味著緊密耦合。在某些情況下這很糟糕，在其他情況下則很好。因此，我不願在*已釋出的* API中使用繼承，但它經常在* private * API中具有很大的價值。我們有一個Payment類，它針對每個用例進行了擴充套件，但這是一個封閉的私有API。即核心應用程式的一部分。這是繼承具有巨大利益的一個完美例子，但它處於受控制的環境中。

11. 在某些語言中，使用繼承似乎效能更高，因為它是在編譯器級別實現的，使用組合有時需要不同的例項，更多的記憶體，有時還會失去靜態排程的好處