來源：blog.csdn.net/fuzhongmin05/article/details/108646872
面向物件編程中，有一條非常經典的設計原則，那就是：組合優于繼承，多用組合少用繼承，
同樣地，在《阿里巴巴Java開發手冊》中有一條規定：謹慎使用繼承的方式進行擴展，優先使用組合的方式實作， 這個可以在公眾號Java核心技識訓復：手冊，獲取最新高清完整版PDF，
為什么不推薦使用繼承
每個人在剛剛學習面向物件編程時都會覺得：繼承可以實作類的復用，所以，很多開發人員在需要復用一些代碼的時候會很自然的使用類的繼承的方式，因為書上就是這么寫的，繼承是面向物件的四大特性之一，用來表示類之間的is-a關系，可以解決代碼復用的問題，雖然繼承有諸多作用，但繼承層次過深、過復雜，也會影響到代碼的可維護性，
假設我們要設計一個關于鳥的類，我們將“鳥”這樣一個抽象的事物概念，定義為一個抽象類AbstractBird，所有更細分的鳥，比如麻雀、鴿子、烏鴉等，都繼承這個抽象類，我們知道，大部分鳥都會飛，那我們可不可以在 AbstractBird抽象類中，定義一個fly()方法呢？
答案是否定的，盡管大部分鳥都會飛，但也有特例，比如鴕鳥就不會飛，鴕鳥繼承具有fly()方法的父類，那鴕鳥就具有“飛”這樣的行為，這顯然不對，如果在鴕鳥這個子類中重寫fly() 方法，讓它拋出UnSupportedMethodException例外呢？
具體的代碼實作如下所示：
public class AbstractBird {
//...省略其他屬性和方法...
public void fly() { //... }
}
public class Ostrich extends AbstractBird { //鴕鳥
//...省略其他屬性和方法...
public void fly() {
throw new UnSupportedMethodException("I can't fly.'");
}
}
這種寫法雖然可以解決問題，但不優雅，因為除了鴕鳥之外，不會飛的鳥還有很多，比如企鵝，對于這些不會飛的鳥來說，全部都去重寫fly()方法，拋出例外，完全屬于代碼重復，理論上這些不會飛的鳥根本就不應該擁有fly()方法，讓不會飛的鳥暴露fly()介面給外部，增加了被誤用的概率，
要解決上面的問題，就得讓AbstractBird類派生出兩個更加細分的抽象類：會飛的鳥類AbstractFlyableBird和不會飛的鳥類AbstractUnFlyableBird，讓麻雀、烏鴉這些會飛的鳥都繼承 AbstractFlyableBird，讓鴕鳥、企鵝這些不會飛的鳥，都繼承 AbstractUnFlyableBird 類，
具體的繼承關系如下圖所示：
這樣一來，繼承關系變成了三層，但是如果我們不只關注“鳥會不會飛”，還要繼續關注“鳥會不會叫”，將鳥劃分得更加細致時呢？兩個關注行為自由搭配起來會產生四種情況：會飛會叫、不會飛會叫、會飛不會叫、不會飛不會叫，如果繼續沿用剛才的設計思路，繼承層次會再次加深，
如果繼續增加“鳥會不會下蛋”這樣的行為，類的繼承層次會越來越深、繼承關系會越來越復雜，而這種層次很深、很復雜的繼承關系，一方面，會導致代碼的可讀性變差，因為我們要搞清楚某個類具有哪些方法、屬性，必須閱讀父類的代碼、父類的父類的代碼……一直追溯到最頂層父類的代碼，另一方面，這也破壞了類的封裝特性，將父類的實作細節暴露給了子類，子類的實作依賴父類的實作，兩者高度耦合，一旦父類代碼修改，就會影響所有子類的邏輯，
繼承最大的問題就在于：繼承層次過深、繼承關系過于復雜時會影響到代碼的可讀性和可維護性，
組合相比繼承有哪些優勢
復用性是面向物件技術帶來的很棒的潛在好處之一，如果運用的好的話可以幫助我們節省很多開發時間，提升開發效率，但是，如果被濫用那么就可能產生很多難以維護的代碼，作為一門面向物件開發的語言，代碼復用是Java引人注意的功能之一，Java代碼的復用有繼承、組合以及委托三種具體的實作形式，
對于上面提到的繼承帶來的問題，可以利用組合（composition）、介面、委托（delegation）三個技術手段一塊兒來解決，
介面表示具有某種行為特性，針對“會飛”這樣一個行為特性，我們可以定義一個Flyable介面，只讓會飛的鳥去實作這個介面，對于會叫、會下蛋這些行為特性，我們可以類似地定義Tweetable介面、EggLayable介面，我們將這個設計思路翻譯成Java代碼的話，就是下面這個樣子：
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 implements 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(); // 委托
}
}
使用Java8的介面默認方法
在Java8中，我們可以在介面中寫默認實作方法，使用關鍵字default定義默認介面實作，當然這個默認的方法也可以重寫，
public interface Flyable {
default void fly() {
//默認實作...
}
}
public interface Flyable {
default void fly() {
//默認實作...
}
}
public interface Tweetable {
default void tweet() {
//默認實作...
}
}
public interface EggLayable {
default void layEgg() {
//默認實作...
}
}
public class Ostrich implements Tweetable, EggLayable {//鴕鳥
//... 省略其他屬性和方法...
}
public class Sparrow implements Flayable, Tweetable, EggLayable {//麻雀
//... 省略其他屬性和方法...
}
繼承主要有三個作用：表示is-a關系、支持多型特性、代碼復用，而這三個作用都可以通過其他技術手段來達成，比如is-a關系，我們可以通過組合和介面的has-a關系來替代；多型特性我們也可以利用介面來實作；代碼復用我們可以通過組合和委托來實作，所以，從理論上講，通過組合、介面、委托三個技術手段，我們完全可以替換掉繼承，在專案中不用或者少用繼承關系，特別是一些復雜的繼承關系，
如何判斷該用組合還是繼承
盡管我們鼓勵多用組合少用繼承，但組合也并不是完美的，繼承也并非一無是處，從上面的例子來看，繼承改寫成組合意味著要做更細粒度的類的拆分，這也就意味著，我們要定義更多的類和介面，類和介面的增多也就或多或少地增加代碼的復雜程度和維護成本，如果類之間的繼承結構穩定（不會輕易改變），繼承層次比較淺（比如，最多有兩層繼承關系），繼承關系不復雜，我們就可以大膽地使用繼承，反之，系統越不穩定，繼承層次很深，繼承關系復雜，我們就盡量使用組合來替代繼承，
除此之外，還有一些設計模式會固定使用繼承或者組合，比如，裝飾者模式（decorator pattern）、策略模式（strategy pattern）、組合模式（composite pattern）等都使用了組合關系，而模板模式（template pattern）使用了繼承關系，
有的地方提到組合優先繼承這條軟體開發原則時，可能會說成“多用組合，少用繼承”，所謂多用與少用，實際指的是要弄清楚在具體的場景下需要哪種，軟體開發原則這類問題，不宜死扣字眼，其實在《Thinking in Java》里有提到，當你用繼承的時候，肯定是想要使用多型的特性，
比如你要寫一個畫圖系統，畫不同的圖形，這個時候，你可能考慮到呼叫相應的函式的時候可以不考慮具體型別，直接畫就好了，具體什么圖形，交給運行時去判斷，這個時候，就要用到多型，就需要有繼承關系，一個父類，多個子類，然后用父類的型別去參考具體子類的物件，就可以了，
而用不到多型的時候，使用繼承有什么用呢？代碼復用？一個繼承可以讓你少寫很多代碼，但是用錯了場合，后期的維護可能是災難性的，因為繼承關系的耦合度很高，一處改會導致處處需要修改，這個時候就需要組合，
所以我堅持，如果不想使用多型特性，繼承關系就是無用的，
處境尷尬的繼承
大家對繼承的厭惡主要是因為長期以來程式員過度使用繼承，繼承并非一無是處，
在某些特殊場景下，我們必須使用繼承，如果你不能改變一個函式的入參型別，而入參又非介面，為了支持多型，只能采用繼承來實作，比如下面這樣一段代碼，其中FeignClient是一個外部類，我們無法修改這個外部類，但是我們希望能重寫這個類在運行時執行的encode() 函式，這個時候，我們只能采用繼承來實作了，
public class FeignClient { // Feign 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);
上面這個例子，舉得不是太恰當，更像是一種迫不得已，這恰好反映了繼承在面向物件編程的大部分場景下的尷尬處境，
其實我們很難真正使用好繼承，根本原因在于，自然界中，代際之間是存在變異的，物種之間也是，而且這種變化是無法做規律化描述的，既伴隨著某些功能的增加，也伴隨著某些功能的榷訓，甚至還有某些功能的改變，
在軟體行業最早期，軟體功能很貧乏，需要不斷增加軟體功能來滿足需求，這時候繼承關系能夠體現軟體迭代后功能增強的特點，但很快就達到瓶頸期，功能不再是衡量軟體好壞的主要指標，各種差異化的體驗變得更加重要，此時軟體迭代時不再是單純的功能的累加，甚至于是完全的推倒重來，編程語言上的繼承關系也就隨之被廢棄，
注：以上關于組合及繼承的代碼例子，出自極客時間王爭老師的《設計模式之美》第十講
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/436939.html
標籤：Java
上一篇：四、Java基礎