聊聊關于Java方法重寫的反思

更新時間：2023年05月24日 17:05:07 作者：樂征skyline

最近在開發(fā)中遇到一個關于Java方法重寫的一些問題，對于方法重寫的用法以及可能導致的問題產生了一些思考，本文用于記錄下這些想法，希望對大家也有所幫助

問題場景

我們首先來看兩段代碼：

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

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

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

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

原本Activity類中默認實現是個空方法：

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

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

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

問題分析

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

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

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

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