編程中用不好重載就別用！關于重載逼到人發瘋的案例！

“重載”會逼瘋一個程序員嗎？會！當重載在代碼中無處不在時，真的會讓一個接手他人代碼的程序員分分鐘陷入崩潰！重載出現的本意是當一個函數的默認實現滿足不了現實需求的時候，使用重?載則可以直接打破函數原有邏輯或者在原有邏輯上追加邏輯，大大方便了程序的擴展性，但是，我們公司有一個“大牛”他的重載用法，我看了真的很難受！

先說下重載的用法，首先你得繼承一個基類，這個基類中需要定義一個“虛方法”，大多數編程語言中，虛方法需要使用virtual關鍵字來裝飾，然后繼承這個基類的實體類需要重載這個虛方法，一般使用protected override關鍵字來聲明重載。

當然，虛方法中你可以定義一些基礎實現，也可以完全不用實現任何邏輯，但是，不實現任何邏輯的話，完全只為了讓外部重載這種用法不建議，因為這樣的話，你完全可以不用定義基類和虛方法，聲明一個接口就完全符合你的要求了！

我們公司的“大牛”使用虛方法的原因就是他想在某些操作中統一去執行一些東西，比如說一些確定和取消按鈕，當點擊時需要關閉窗口或者頁面，所以，但凡是按鈕的確認和取消功能他都繼承了含有虛方法的基類，然后直接調用重載方法去執行頁面的關閉邏輯！

乍一看好像沒什么毛病，基類的結構也很簡單，里面有兩個虛方法，一個確認方法，一個取消方法，每個需方法里面只加了一行代碼，用來執行關閉窗口或者頁面的委托（或者說邏輯）。

如果你直接調用虛方法的重載實現我都沒什么話說，主要是在虛方法的基類基礎上又加了兩個轉發函數，外部在調用虛方法時不直接調用，而是先調用兩個轉發函數，由轉發函數去執行基類虛方法的實現！

他這么做的原因是因為代碼框架中確定和取消按鈕必須先實現代碼框架定義的系統基類中的兩個虛方法，分別是確定和取消。

這么一來，其實他自己定義的基類和系統基類中的虛方法其實就沖突了，而為了硬調用他自己寫的基類，因此就有了上面所說的轉發函數。

這兩個轉發函數是做什么用的呢？其實道理也很簡單，因為代碼框架要求確定和取消必須先實現系統函數，因此，他在自己寫的基類中線定義了一個系統函數的實現，這樣確定和取消按鈕就可以直接調用這個實現。

但是，光調用實現不行，自己定義的虛方法也需要實現，因此，在這個實現的基礎上，又調用了對應的虛方法，在前端層面，也就是直接調用了虛方法的重載！

是不是很繞？我在看這段代碼的時候，其實我也被繞了，雖然道理很簡單，但是這種“硬控”代碼，我欣賞不來！

最主要的是，當我想要定位按鈕的實現時，我只能定位到系統函數的實現，但是，因為系統函數的實現是被他寫在虛方法的基類中的，因此，我在定位函數實現的時候首先會被定位到他自己實現的函數基類中。

如果此時你是第一次看他的代碼，你會完全摸不著頭腦，因為你到現在還沒發現函數的真正實現直到我去仔細觀賞他在基類里面寫的代碼，我才知道：哦，原來他是通過調用這個函數，然后去調用那個虛方法的實現的，所以，我應該去前端找這個名字的虛方法的對應的方法實現！

能明白我的糾結點嗎？比如說我要干一件事情，A明明知道我需要干什么事情，當我去問A時，A說他按照流程，得先讓我去B那過一下，由B把任務發布給我，然后我到了B那以后，B告訴我，我的任務就是去A那執行！

能明白嗎？B的作用只是中轉！且如果不經過B，A是不會告訴我具體應該執行什么東西的！

如果代碼中到處都充斥著這種代碼，那我在閱讀代碼時就需要來來回回折騰：先定位方法-定位到基類-在基類里面找方法的虛方法-回到原方法去找虛方法的實現！

除非你對這套代碼很熟，否則一定會被代碼給繞進去。

我想了很久，他這么干的意圖是什么，最后，我沒有看到任何好處，只有一點，那就是的確代碼變得優雅了。

首先，我們公司做的都是非標自動化項目，排除一些常用的硬件、通訊協議、UI我們會封裝成庫外，其他的基本上每個項目的代碼邏輯都不一樣，而且，后續再動代碼的可能性極小，即使是客戶想要新增功能，也不會出現大改的情況。

反而是一個項目代碼部署出去可能等第二次客戶要求增加功能時，因為我們這個行業程序員流動性比較大，因此，到那個時候當初寫這套代碼的人可能都不在了！

因此，代碼的可讀性是最重要的，代碼的可讀性上來了，應對突發狀況的反應時間也就會很快，也會減少客戶那邊停機的損失。

結語

所以，別扯什么設計模式，有些時候，代碼優雅的能開香檳，也不及讓一個剛畢業的程序員能看懂來得實際！而一般維護這些已經交付的項目的人，恰恰就是那些經驗稍淺一些的程序員！

所以，我最后嘆了一口氣，因為我改變不了什么，代碼本身是來解決問題的，但是有些時候代碼寫得太通俗易懂反而會被人說成“幼稚”、“不夠優雅”。