31 天重構學習筆記25 引入契約式設計

摘要：由於最近在做重構的專案，所以對重構又重新進行了一遍學習和整理，對31天重構最早接觸是在2023年10月份，由於當時沒有訂閱

sean chambers的blog，所以是在國外的社群上閒逛的時候鏈結過去的。記得當時一口氣看完了整個系列並沒有多少感覺，因為這些基本上專案都在使用，只是我們沒有專門把它標示和整理出來，所以也沒有引起多大的重視。現在突然接手這個重構專案，由於團隊成員技術和經驗參差不齊，所以有必要專門整理乙個重構的綱要，當然這個系列也非常適合做新系統的**規範參考，只要有**的地方，這個重構規範就很有價值。週末也不想出去閒逛，因為在剛到這個美麗的城市，沒有親戚或者朋友，所以才能靜下心來兩天時間寫完這個重構參考規範。同時也感受了windows live writer寫文章的快感。當然重構的整體架構得另當別論（整體架構在我的這篇文章有專門的講解（

大的架構設計好了以後，這些重構細節點就成了東風之後的大火，對整個專案也是至關重要。31天重構這個系列和《**大全》、《重構：改善既有**的設計》比較起來最大的特點就是比較簡單、淺顯易懂。那麼我這些文章也都是學習sean chambers的31天重構的筆記整理，所以如果大家對這個筆記有任何異議也可以指出，具體也可以通過

查看原文。

概念：本文中的」引入契約式設計」是指我們應該對應該對輸入和輸出進行驗證，以確保系統不會出現我們所想象不到的異常和得不到我們想要的結果。

正文：契約式設計規定方法應該對輸入和輸出進行驗證，這樣你便可以保證你得到的資料是可以工作的，一切都是按預期進行的，如果不是按預期進行，異常或是錯誤就應該被返回，下面我們舉的例子中，我們方法中的引數可能會值為null的情況，在這種情況下由於我們沒有驗證，nullreferenceexception異常會報出。另外在方法的結尾處我們也沒***會返回乙個正確的decimal值給呼叫方法的物件。

using system;
using system.collections.generic;
using system.linq;
using system.text;
namespace lostechies.daysofrefactoring.samplecode.day25_designbycontract
}}

對上面的**重構是很簡單的，首先我們處理不會有乙個null值的customer物件，檢查我們最少會有乙個product物件。在返回訂單總和之前先確保

我們會返回乙個有意義的值。如果上面說的檢查有任何乙個失敗，我們就丟擲對應的異常，並在異常裡說明錯誤的詳細資訊，而不是直接丟擲nullreferenceexception。

using system;
using system.collections.generic;
using system.linq;
using system.text;
using microsoft.contracts;
namespace lostechies.daysofrefactoring.samplecode.designbycontract.after
}}

上面的**中新增了額外的**來進行驗證，雖然看起來**複雜度增加了，但我認為這是非常值得做的，因為當nullreferenceexception發生時去追查異常的詳細資訊

真是很令人討厭的事情。

總結：微軟在處理**乃至產品的時候，很喜歡應用此重構，你如果認真看它的**庫，認真看一下wcf的設計，就不難發現了。這個重構建議大家經常使用，

這會增強整個系統的穩定性和健壯性。

31 天重構學習筆記25 引入契約式設計

31天重構學習筆記25 引入契約式設計

31 天重構學習筆記23 引入引數物件

31 天重構學習筆記索引

31 天重構學習筆記25 引入契約式設計

31天重構學習筆記25 引入契約式設計

31 天重構學習筆記23 引入引數物件

31 天重構學習筆記索引

相關推薦