最近在開發(fā)中遇到一個關(guān)于Java方法重寫的一些問題，對于方法重寫的用法以及可能導(dǎo)致的問題產(chǎn)生了一些思考，本文用于記錄下這些想法。

問題場景

我們首先來看兩段代碼：

@Override
protected void onActivityResult(int requestCode, int resultCode, @Nullable Intent data) {
    super.onActivityResult(requestCode, resultCode, data);
    switch (requestCode){
        case TAKE_PHOTO_CODE:{
            //處理拍照得到的結(jié)果
            break;
        }
        case CHOOSE_FROM_ALBUM_CODE:{
            //處理相冊選取到的結(jié)果
            break;
        }
    }
}

@Override
protected void onActivityResult(int requestCode, int resultCode, @Nullable Intent data) {
    switch (requestCode){
        case TAKE_PHOTO_CODE:{
            //處理拍照得到的結(jié)果
            break;
        }
        case CHOOSE_FROM_ALBUM_CODE:{
            //處理相冊選取到的結(jié)果
            break;
        }
        default:{
            super.onActivityResult(requestCode, resultCode, data);
        }
    }
}

這兩段代碼是Android開發(fā)中處理Activity結(jié)果的示例。Android啟動新頁面后，新頁面設(shè)置完結(jié)果返回的時候，舊頁面可以從這個方法得到新頁面的結(jié)果。來自不同頁面的結(jié)果按照參數(shù)中的requestCode來區(qū)分，這個requestCode和啟動新頁面時傳遞的對應(yīng)，也就是說一個requestCode標(biāo)識一個頁面請求和一個結(jié)果類型。例如，上面示例模擬的是常見APP中換用戶頭像的功能，結(jié)果有兩種：1. 拍照得到的結(jié)果；2. 相冊選取得到的結(jié)果。

上面兩種方法就結(jié)果來說都是對的，但是表達(dá)的意義不同：第一種寫法是純粹地擴(kuò)展父類的方法，父類干的事它都干；而第二種寫法是改寫父類的方法，相當(dāng)于重定義并依賴了父類的行為，或者說對父類行為做了攔截、訪問控制。

原本Activity類中默認(rèn)實現(xiàn)是個空方法：

protected void onActivityResult(int requestCode, int resultCode, Intent data) {
}

這種情況下兩種寫法的行為差異完全可以忽略不計，但是實際開發(fā)中我們一般繼承自FragmentActivity或AppCompatActivity，這兩個類都對這個方法做了相應(yīng)的實現(xiàn)，在這種情況下，第一種寫法父類的實現(xiàn)一定會被執(zhí)行，但是第二種寫法可能將父類的實現(xiàn)短路了。這可能導(dǎo)致一些意料之外的問題，比如，Activity和Fragment都對某個requestCode進(jìn)行處理，但第二種寫法會導(dǎo)致Fragment的對應(yīng)onActivityResult方法不會被掉用。

在實際開發(fā)中我們可能會編寫一個BaseActivity，將一些方法實現(xiàn)一下并添加統(tǒng)計和日志，那么第二種寫法也可能導(dǎo)致日志丟失的問題。

問題分析

這個問題讓我聯(lián)想到一個設(shè)計原則：里氏替換原則（Liskov Substitution principle）。這個原則說明：派生類（子類）對象可以在程序中代替其基類（超類）對象。這表示程序中任何父類對象可以出現(xiàn)的位置，子類的對象都可將其替代。進(jìn)一步解讀，就是意味著子類可以擴(kuò)展父類的功能，但不能改變父類原有的功能。

這個原則考慮了安全性。編程時為了降低耦合度，通常面向抽象數(shù)據(jù)類型（例如接口、抽象類等）來編寫，而父類在編寫的時候也不會去考慮子類的實現(xiàn)，那么就要求子類的實現(xiàn)的時候需要顧及父類的運(yùn)行。

那么當(dāng)我們在重寫父類方法的時候，情況就復(fù)雜了起來，具體分為以下幾種情況：

• 當(dāng)父類代碼和子類代碼都是同一個人負(fù)責(zé)的時候，并且在代碼同一項目、同一模塊。這種情況比較安全，因為編寫子類實現(xiàn)的人是完全了解并掌控父類實現(xiàn)的；
• 當(dāng)父類代碼和子類代碼是同一個人負(fù)責(zé)的時候，而代碼位于不同項目。例如，一個人同時維護(hù)一個應(yīng)用項目和一個獨立框架。這種情況，就可能出隱患，因為隨著項目進(jìn)行，這個框架中的父類可能被多個應(yīng)用項目使用，這個父類就可能無法兼顧多個項目的場景和用法，而導(dǎo)致子類實現(xiàn)中錯誤地改寫父類的方法。
• 當(dāng)父類代碼和子類代碼時不同的人負(fù)責(zé)，且代碼位于不同項目時，這種情況就比較危險了。因為父類實現(xiàn)的行為實現(xiàn)和行為變更很可能是不透明的、未知的，而且父類的實現(xiàn)可能不會顧及到子類的應(yīng)用。那么當(dāng)子類改寫父類行為的時候，當(dāng)父類行為發(fā)生變更，那么子類的實現(xiàn)很可能是有問題的。

方法與建議

針對上面所提到的三種情況，我思考了如下三個對應(yīng)的建議：

• 針對第一種安全的情況，盡量不改寫父類方法，在子類和父類實現(xiàn)中盡量補(bǔ)充注釋和注解說明；
• 針對第二種有隱患的情況，盡量不改寫父類方法，父類設(shè)計無法涵蓋所有場景時，適當(dāng)時候重構(gòu)父類代碼，而不是讓子類通過“hack”的手段曲線救國。
• 針對第三種危險的情況，一定不要改寫父類方法，可以考慮在方法第一行就super調(diào)用。

到此這篇關(guān)于聊聊關(guān)于Java方法重寫的反思的文章就介紹到這了,更多相關(guān)Java方法重寫內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論