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

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

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

我們公司的“大?！笔褂锰摲椒ǖ脑蚓褪撬朐谀承┎僮髦薪y(tǒng)一去執(zhí)行一些東西，比如說一些確定和取消按鈕，當(dāng)點擊時需要關(guān)閉窗口或者頁面，所以，但凡是按鈕的確認和取消功能他都繼承了含有虛方法的基類，然后直接調(diào)用重載方法去執(zhí)行頁面的關(guān)閉邏輯！

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

如果你直接調(diào)用虛方法的重載實現(xiàn)我都沒什么話說，主要是在虛方法的基類基礎(chǔ)上又加了兩個轉(zhuǎn)發(fā)函數(shù)，外部在調(diào)用虛方法時不直接調(diào)用，而是先調(diào)用兩個轉(zhuǎn)發(fā)函數(shù)，由轉(zhuǎn)發(fā)函數(shù)去執(zhí)行基類虛方法的實現(xiàn)！

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

這么一來，其實他自己定義的基類和系統(tǒng)基類中的虛方法其實就沖突了，而為了硬調(diào)用他自己寫的基類，因此就有了上面所說的轉(zhuǎn)發(fā)函數(shù)。

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

但是，光調(diào)用實現(xiàn)不行，自己定義的虛方法也需要實現(xiàn)，因此，在這個實現(xiàn)的基礎(chǔ)上，又調(diào)用了對應(yīng)的虛方法，在前端層面，也就是直接調(diào)用了虛方法的重載！

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

最主要的是，當(dāng)我想要定位按鈕的實現(xiàn)時，我只能定位到系統(tǒng)函數(shù)的實現(xiàn)，但是，因為系統(tǒng)函數(shù)的實現(xiàn)是被他寫在虛方法的基類中的，因此，我在定位函數(shù)實現(xiàn)的時候首先會被定位到他自己實現(xiàn)的函數(shù)基類中。

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

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

能明白嗎？B的作用只是中轉(zhuǎn)！且如果不經(jīng)過B，A是不會告訴我具體應(yīng)該執(zhí)行什么東西的！

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

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

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

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

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

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

結(jié)語

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

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