在面向對象編程中，有一條非常經典的設計原則，那就是：組合優於繼承，多用組合少用繼承。為什么不推薦使用繼承？組合相比繼承有哪些優勢？如何判斷該用組合還是繼承？今天，我們就圍繞着這三個問題，來詳細講解一下這條設計原則。
為什么不推薦使用繼承？
繼承是面向對象的四大特性之一，用來表示類之間的 is-a 關系，可以解決代碼復用的問題。雖然繼承有諸多作用，但繼承層次過深、過復雜，也會影響到代碼的可維護性。所以，對於是否應該在項目中使用繼承，網上有很多爭議。很多人覺得繼承是一種反模式，應該盡量少用，甚至不用。為什么會有這樣的爭議？我們通過一個例子來解釋一下。
假設我們要設計一個關於鳥的類。我們將“鳥類”這樣一個抽象的事物概念，定義為一個抽象類 AbstractBird。所有更細分的鳥，比如麻雀、鴿子、烏鴉等，都繼承這個抽象類。
我們知道，大部分鳥都會飛，那我們可不可以在 AbstractBird 抽象類中，定義一個 fly() 方法呢？答案是否定的。盡管大部分鳥都會飛，但也有特例，比如鴕鳥就不會飛。鴕鳥繼承具有 fly() 方法的父類，那鴕鳥就具有“飛”這樣的行為，這顯然不符合我們對現實世界中事物的認識。當然，你可能會說，我在鴕鳥這個子類中重寫（override）fly() 方法，讓它拋出 UnSupportedMethodException 異常不就可以了嗎？具體的代碼實現如下所示：
public class AbstractBird {
//...省略其他屬性和方法...
public void fly() { //... }
}
public class Ostrich extends AbstractBird { //鴕鳥
//...省略其他屬性和方法...
public void fly() {
throw new UnSupportedMethodException("I can't fly.'");
}
}
這種設計思路雖然可以解決問題，但不夠優美。因為除了鴕鳥之外，不會飛的鳥還有很多，比如企鵝。對於這些不會飛的鳥來說，我們都需要重寫 fly() 方法，拋出異常。這樣的設計，一方面，徒增了編碼的工作量；另一方面，也違背了我們之后要講的最小知識原則（Least Knowledge Principle，也叫最少知識原則或者迪米特法則），暴露不該暴露的接口給外部，增加了類使用過程中被誤用的概率。
可能又會說，那我們再通過 AbstractBird 類派生出兩個更加細分的抽象類：會飛的鳥類 AbstractFlyableBird 和不會飛的鳥類 AbstractUnFlyableBird，讓麻雀、烏鴉這些會飛的鳥都繼承 AbstractFlyableBird，讓鴕鳥、企鵝這些不會飛的鳥，都繼承 AbstractUnFlyableBird 類，不就可以了嗎？具體的繼承關系如下圖所示：
從圖中我們可以看出，繼承關系變成了三層。不過，整體上來講，目前的繼承關系還比較簡單，層次比較淺，也算是一種可以接受的設計思路。我們再繼續加點難度。在剛剛這個場景中，我們只關注“鳥會不會飛”，但如果我們還關注“鳥會不會叫”，那這個時候，我們又該如何設計類之間的繼承關系呢？
是否會飛？是否會叫？兩個行為搭配起來會產生四種情況：會飛會叫、不會飛會叫、會飛不會叫、不會飛不會叫。如果我們繼續沿用剛才的設計思路，那就需要再定義四個抽象類（AbstractFlyableTweetableBird、AbstractFlyableUnTweetableBird、AbstractUnFlyableTweetableBird、AbstractUnFlyableUnTweetableBird）。
如果我們還需要考慮“是否會下蛋”這樣一個行為，那估計就要組合爆炸了。類的繼承層次會越來越深、繼承關系會越來越復雜。而這種層次很深、很復雜的繼承關系，一方面，會導致代碼的可讀性變差。因為我們要搞清楚某個類具有哪些方法、屬性，必須閱讀父類的代碼、父類的父類的代碼……一直追溯到最頂層父類的代碼。另一方面，這也破壞了類的封裝特性，將父類的實現細節暴露給了子類。子類的實現依賴父類的實現，兩者高度耦合，一旦父類代碼修改，就會影響所有子類的邏輯。
總之，繼承最大的問題就在於：繼承層次過深、繼承關系過於復雜會影響到代碼的可讀性和可維護性。這也是為什么我們不推薦使用繼承。那剛剛例子中繼承存在的問題，我們又該如何來解決呢？你可以先自己思考一下，再聽我下面的講解。
組合相比繼承有哪些優勢？
實際上，我們可以利用組合（composition）、接口、委托（delegation）三個技術手段，一塊兒來解決剛剛繼承存在的問題。
我們前面講到接口的時候說過，接口表示具有某種行為特性。針對“會飛”這樣一個行為特性，我們可以定義一個 Flyable 接口，只讓會飛的鳥去實現這個接口。對於會叫、會下蛋這些行為特性，我們可以類似地定義 Tweetable 接口、EggLayable 接口。
public interface Flyable {
void fly();
}
public interface Tweetable {
void tweet();
}
public interface EggLayable {
void layEgg();
}
public class Ostrich implements Tweetable, EggLayable {//鴕鳥
//... 省略其他屬性和方法...
@Override
public void tweet() { //... }
@Override
public void layEgg() { //... }
}
public class Sparrow impelents Flayable, Tweetable, EggLayable {//麻雀
//... 省略其他屬性和方法...
@Override
public void fly() { //... }
@Override
public void tweet() { //... }
@Override
public void layEgg() { //... }
}
不過，我們知道，接口只聲明方法，不定義實現。也就是說，每個會下蛋的鳥都要實現一遍 layEgg() 方法，並且實現邏輯是一樣的，這就會導致代碼重復的問題。那這個問題又該如何解決呢？
我們可以針對三個接口再定義三個實現類，它們分別是：實現了 fly() 方法的 FlyAbility 類、實現了 tweet() 方法的 TweetAbility 類、實現了 layEgg() 方法的 EggLayAbility 類。然后，通過組合和委托技術來消除代碼重復。具體的代碼實現如下所示：
public interface Flyable {
void fly()；
}
public class FlyAbility implements Flyable {
@Override
public void fly() { //... }
}
//省略Tweetable/TweetAbility/EggLayable/EggLayAbility
public class Ostrich implements Tweetable, EggLayable {//鴕鳥
private TweetAbility tweetAbility = new TweetAbility(); //組合
private EggLayAbility eggLayAbility = new EggLayAbility(); //組合
//... 省略其他屬性和方法...
@Override
public void tweet() {
tweetAbility.tweet(); // 委托
}
@Override
public void layEgg() {
eggLayAbility.layEgg(); // 委托
}
}
我們知道繼承主要有三個作用：表示 is-a 關系，支持多態特性，代碼復用。而這三個作用都可以通過其他技術手段來達成。比如 is-a 關系，我們可以通過組合和接口的 has-a 關系來替代；多態特性我們可以利用接口來實現；代碼復用我們可以通過組合和委托來實現。所以，從理論上講，通過組合、接口、委托三個技術手段，我們完全可以替換掉繼承，在項目中不用或者少用繼承關系，特別是一些復雜的繼承關系。
如何判斷該用組合還是繼承？
盡管我們鼓勵多用組合少用繼承，但組合也並不是完美的，繼承也並非一無是處。從上面的例子來看，繼承改寫成組合意味着要做更細粒度的類的拆分。這也就意味着，我們要定義更多的類和接口。類和接口的增多也就或多或少地增加代碼的復雜程度和維護成本。所以，在實際的項目開發中，我們還是要根據具體的情況，來具體選擇該用繼承還是組合。
如果類之間的繼承結構穩定（不會輕易改變），繼承層次比較淺（比如，最多有兩層繼承關系），繼承關系不復雜，我們就可以大膽地使用繼承。反之，系統越不穩定，繼承層次很深，繼承關系復雜，我們就盡量使用組合來替代繼承。
除此之外，還有一些設計模式會固定使用繼承或者組合。比如，裝飾者模式（decorator pattern）、策略模式（strategy pattern）、組合模式（composite pattern）等都使用了組合關系，而模板模式（template pattern）使用了繼承關系。
前面我們講到繼承可以實現代碼復用。利用繼承特性，我們把相同的屬性和方法，抽取出來，定義到父類中。子類復用父類中的屬性和方法，達到代碼復用的目的。但是，有的時候，從業務含義上，A 類和 B 類並不一定具有繼承關系。比如，Crawler 類和 PageAnalyzer 類，它們都用到了 URL 拼接和分割的功能，但並不具有繼承關系（既不是父子關系，也不是兄弟關系）。僅僅為了代碼復用，生硬地抽象出一個父類出來，會影響到代碼的可讀性。如果不熟悉背后設計思路的同事，發現 Crawler 類和 PageAnalyzer 類繼承同一個父類，而父類中定義的卻只是 URL 相關的操作，會覺得這個代碼寫得莫名其妙，理解不了。這個時候，使用組合就更加合理、更加靈活。具體的代碼實現如下所示：
public class Url {
//...省略屬性和方法
}
public class Crawler {
private Url url; // 組合
public Crawler() {
this.url = new Url();
}
//...
}
public class PageAnalyzer {
private Url url; // 組合
public PageAnalyzer() {
this.url = new Url();
}
//..
}
還有一些特殊的場景要求我們必須使用繼承。如果你不能改變一個函數的入參類型，而入參又非接口，為了支持多態，只能采用繼承來實現。比如下面這樣一段代碼，其中 FeignClient 是一個外部類，我們沒有權限去修改這部分代碼，但是我們希望能重寫這個類在運行時執行的 encode() 函數。這個時候，我們只能采用繼承來實現了。
public class FeignClient { // feighn client框架代碼
//...省略其他代碼...
public void encode(String url) { //... }
}
public void demofunction(FeignClient feignClient) {
//...
feignClient.encode(url);
//...
}
public class CustomizedFeignClient extends FeignClient {
@Override
public void encode(String url) { //...重寫encode的實現...}
}
// 調用
FeignClient client = new CustomizedFeignClient();
demofunction(client);
盡管有些人說，要杜絕繼承，100% 用組合代替繼承，但是我的觀點沒那么極端！之所以“多用組合少用繼承”這個口號喊得這么響，只是因為，長期以來，我們過度使用繼承。還是那句話，組合並不完美，繼承也不是一無是處。只要我們控制好它們的副作用、發揮它們各自的優勢，在不同的場合下，恰當地選擇使用繼承還是組合，這才是我們所追求的境界。
重點回顧
為什么不推薦使用繼承？
繼承是面向對象的四大特性之一，用來表示類之間的 is-a 關系，可以解決代碼復用的問題。雖然繼承有諸多作用，但繼承層次過深、過復雜，也會影響到代碼的可維護性。在這種情況下，我們應該盡量少用，甚至不用繼承。
組合相比繼承有哪些優勢？
繼承主要有三個作用：表示 is-a 關系，支持多態特性，代碼復用。而這三個作用都可以通過組合、接口、委托三個技術手段來達成。除此之外，利用組合還能解決層次過深、過復雜的繼承關系影響代碼可維護性的問題。
如何判斷該用組合還是繼承？
盡管我們鼓勵多用組合少用繼承，但組合也並不是完美的，繼承也並非一無是處。在實際的項目開發中，我們還是要根據具體的情況，來選擇該用繼承還是組合。如果類之間的繼承結構穩定，層次比較淺，關系不復雜，我們就可以大膽地使用繼承。反之，我們就盡量使用組合來替代繼承。除此之外，還有一些設計模式、特殊的應用場景，會固定使用繼承或者組合。