#### [放松 DbC 檢查或非嚴格的 DbC](https://lingcoder.gitee.io/onjava8/#/book/16-Validating-Your-Code?id=%e6%94%be%e6%9d%be-dbc-%e6%a3%80%e6%9f%a5%e6%88%96%e9%9d%9e%e4%b8%a5%e6%a0%bc%e7%9a%84-dbc) 盡管 Meyer 強調了前置條件、后置條件和不變性的價值以及在開發過程中使用它們的重要性，他承認在一個產品中包含所有 DbC 代碼并不總是實際的。你可以基于對特定位置的代碼的信任程度放松 DbC 檢查。以下是放松檢查的順序，最安全到最不安全： **1**. 不變性檢查在每個方法一開始的時候是不能進行的，因為在每個方法結束的時候進行不變性檢查能保證一開始的時候對象處于有效狀態。也就是說，通常情況下，你可以相信對象的狀態不會在方法調用之間發生變化。這是一個非常安全的假設，你可以只在代碼末尾使用不變性檢查來編寫代碼。 **2**. 接下來禁用后置條件檢查，當你進行合理的單元測試以驗證方法是否返回了適當的值時。因為不變性檢查是觀察對象的狀態，后置條件檢查僅在方法期間驗證計算結果，因此可能會被丟棄，以便進行單元測試。單元測試不會像運行時后置條件檢查那樣安全，但是它可能已經足夠了，特別是當對自己的代碼有信心時。 **3**. 如果你確信方法主體沒有把對象改成無效狀態，則可以禁用方法調用末尾的不變性檢查。可以通過白盒單元測試(通過訪問私有字段的單元測試來驗證對象狀態)來驗證這一點。盡管它可能沒有調用**invariant()**那么穩妥，可以將不變性檢查從運行時測試 “遷移” 到構建時測試(通過單元測試)，就像使用后置條件一樣。 **4**. 禁用前置條件檢查，但除非這是萬不得已的情況下。因為這是最不安全、最不明智的選擇，因為盡管你知道并且可以控制自己的代碼，但是你無法控制客戶端可能會傳遞給方法的參數。然而，某些情況下對性能要求很高，通過分析得到前置條件造成了這個瓶頸，而且你有某種合理的保證客戶端不會違反前置條件(比如自己編寫客戶端的情況下)，那么禁用前置條件檢查是可接受的。 你不應該直接刪除檢查的代碼，而只需要禁用檢查(添加注釋)。這樣如果發現錯誤，就可以輕松地恢復檢查以快速發現問題。