上海
公司一程序員有一段代碼寫得太亂了，總結下這段代碼的邏輯那就是業務邏輯結束了，需要往很多地方寫入業務結束的處理邏輯，而這個程序員對于業務結束的處理邏輯，我大概看了下，總共寫了大概有3000行左右的代碼，直接給我整崩潰了，原因是他把所有邏輯都寫在了一起，但凡有一個邏輯寫的有問題，代碼都走不下去。
事情的起因是這個程序員寫的軟件總是在業務結束的時候出各種問題，改來改去，最后他自己都給改懵了，最后，項目經理看他腦子已經亂了，于是就讓我幫忙看看他的代碼，看看能不能幫他找出問題來。
他這段代碼是寫在一個工具類里面的，還好，他還知道封裝一個工具類來整合業務結束的處理邏輯，但是一看代碼行，著實給我嚇了一跳，代碼總共有3000多行！
據這個程序員所說，在業務邏輯結束以后，首先得往數據庫里面寫入日志，還得在本地寫入文本日志，最后根據業務的結束狀態，需要往外部發送業務邏輯的結束信號，還得在PLC里面寫入數據和業務狀態，最后我數了一下，前前后后，在這段業務結束的代碼里面總共需要往本地或者外部發送十幾種數據或者狀態。
但是呢，其實業務結束的邏輯本身就幾十行，后面近3000多行代碼都是用來處理數據信號和數據存儲以及狀態的。
最后，雖然我們通過分析，解決了這段代碼中的BUG，但是，面對這3000多行的代碼，我實在忍不了，因為代碼也得太臃腫、太耦合了！
于是我問他：“如果當中有一段邏輯不用了你會怎么辦？”
他想了一會兒，但是也沒想多久，告訴我：“只能把這段代碼給注釋了！”
然后我又問他：“如果這里面又要新增一部分邏輯，你又會怎么辦？”
結果他說：“那就在現在的代碼基礎之上再插入新的邏輯代碼！”
我就知道他會這么說，而且，他也只能這么干！
接著，我又問他：“現在你把所有的業務結束邏輯都寫在了一塊，萬一系統里面有其他的界面需要知道業務結束的狀態，你怎么辦？”
他告訴我：“我在代碼里面加了一個狀態，其他頁面只要監聽這個狀態，就可以了！”
于是我反問：“你會怎么做？”
他回答：“在頁面上加一個定時器，然后一直讀取存儲狀態的變量，發現值變了，就知道業務結束了！”
我無奈地拍了拍腦袋：“萬一，我說萬一，有十幾二十甚至是上百個頁面都需要知道這個狀態，你難道要寫十幾二十甚至上百個計時器嗎？”
這時候，他不說話了，于是我說：“事情不需要那么復雜，只需要一個委托就夠了！”
委托（Delegate），在C#這門編程語言里面又稱事件，簡單得說，委托就是一種對事件的訂閱！通過聲明調用，可以將事件觸發信號分發給訂閱了委托的其他方法中！
比如說，現在代碼中的業務邏輯結束了，我們可以聲明一個委托，然后在業務邏輯結束時調用這個委托，這時候，只要外部代碼訂閱了這個委托，那么它們就會收到委托被執行的消息，具體來說，訂閱委托實際上就是給委托一個執行方法，在委托被執行后，這個執行方法會一起被執行！
現在，在上述程序員寫的業務結束的代碼中集合了十幾種需要處理的邏輯，這時候，我們可以在業務結束的代碼里面聲明一個委托，然后將這十幾種需要處理的邏輯單獨封裝起來，然后訂閱業務結束的委托，當委托被觸發后，這十幾種已經封裝的邏輯塊都將收到事件信號，逐一處理即可。
使用委托的好處在于它可以將繁復的業務邏輯模塊化，從而提升代碼的可讀性和可維護性，而委托本身就是一種狀態機制，因此，上述程序員寫的狀態字段的監聽程序也就沒必要寫了，直接將委托本身當作狀態或者使用委托參數的方式，把狀態傳遞給訂閱者即可。
結語
委托的概念其實很簡單，其實就是“當發生某件事情的時候由事情的發生者告訴訂閱者”，這跟我們手機上的消息推送機制很像，比如說當你關注了某個明星的賬號，當這個明星的賬號下面有了新的動態，你的手機就會在第一時間收到這個明星發送的最新動態。
有一些剛開始使用委托的程序員會覺得委托會增加代碼的復雜性，但是，實際上用對了委托會感覺真香！
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
