1樓：奧利維亞
可以試著從編寫測試用例的角度去考慮dbc
因為對於乙個模組/功能來說
前置條件，確定的輸入，過程邏輯處理，確定的輸出上述被確定的話，對於程式設計來說，可以避免很多程式脆弱性的設計，大白話就是減少很多隱藏的bug
2樓：rainoftime
比如下面的例子，就是對程式的預期行為做檢查。
「行為」可以是前置條件、後置條件、迴圈不變式等，表達的屬性有強有弱：比如純數值的(x > 2)、陣列相關的(sorted)、包含指標的(p -> q)。。「檢查」可以是靜態（通過靜態程式分析、模型檢查等方法）或動態的。
把Contract理解成「Type System"也不算錯，畢竟CS很多術語都是濫用的。。
順便：.NET的Contracts已經開源了，Microsoft/CodeContracts ，靜態檢查部分主要用的是抽象解釋，當然它也被用於減少動態檢查
using
System
;using
System.Linq
using
System.Collections.Generic;using
System.Diagnostics.Contracts;namespace
Microsoft.Z3}}
3樓：lgxZJ
DbC強調在設計層面上保持程式的正確性。1）簡單說就是前置條件（pre-condition）、後置條件（post-condition）和不變式（invariant）, 分別指代函式核心邏輯執行前必須滿足的條件、執行後必須滿足的條件和執行結果必須保持的不變式（某一不變條件）。
2）常見的表現形式就是引數有效性、內部狀態、約束等。
3）Eiffel語法層面原生支援這些概念，通過require、ensure等；其他語言的支援似乎不是很好，常見的只有assert了。
順便插一句，不懂可以直接看看書，挺薄的一本，幾個鐘頭就能看完
4樓：
Design by Contract 往簡單裡說就是語言層面上做引數檢查(precondition)和結果檢查(postcondition)，並保證程式邏輯的不變數(invariant)被保持了，於是程式在執行時要不就是正確的，要不就拋錯。換而言之 DbC 回答了這個 知乎 - 知乎 問題。
DbC 出自形式證明，用更簡單的話說就是「保證程式正確」。如何保證呢？一般的思路是先要保證輸入的引數是正確的，其他程式語言裡一般用 assert 之類的手動加。
而在 DbC 裡叫 precondition，會讓編譯器把寫好的判斷插入到程式主體之前，不需要人手動鑲嵌在主體邏輯裡。之後寫完的結果怎麼才算正確呢？DbC 裡的 postcondition 就是讓人定義判斷來說明這段程式的結果是正確的（比方寫乙個 list reverse 的函式，正確的 reverse 可以呼叫兩次得到原來的 list）。
最後是證明程式正確，就是要抓程式的不變數（invariant）。可參考這篇 wiki Loop invariant - Wikipedia。
在 API 設計上，一般 DbC 有require, ensure, invariant 這幾個程式段，其他答案已經說明了，分別對應了precondition, postcondition。
最後還是要推銷 F*，Refinement Type 能把 require,ensure, invariant直接編譯報錯。
5樓：Belleve
簡而言之的話，讓 Type System 可以以邏輯命題的形式約束執行時行為。
其實這個配合 Coq、Idris、F* 之類的語言才有大用，你程式寫錯直接不給編譯。
怎樣通俗的解釋極化？
激發態的數物演算法 偏離平衡就是極化，存在淨電流。極化的結果，端電壓小於電動勢 被動極化 槽電壓大於理論分解電壓 主動極化 主動極化的原因包括，熱力學沒有考慮濃度差異，沒有考慮氫原子的聚集等動力學因素， 七心海棠 事物發展的本質原因在於矛盾。極化發生的根本原因是電子轉移速度和電極反應速度的矛盾。通常...
不被理解，不想解釋，該怎樣？！
有的時候我也會做一些別人不太理解，甚至覺得奇怪的決定，即是他們會發出質問，你也不好過多解釋。對我來說，我的每乙個重要決定都是深思熟慮，拷問自己內心得到的。因為我非常清楚自己想要什麼。所以每次做決定的時候，我會靜下來問我自己 你想要什麼？什麼對你來說是最重要的？所以做重要決定的時候，我不太會受他人影響...
怎樣向人們解釋自己吃素？
目前來講我都直接說信佛所以吃素，大家對此都表示理解。偶爾會有人質疑，那也無所謂，順便講講佛學 有些人對佛學有很多誤解，所以不理解，但是大多數情況下講講，就當是多點知識，一般也都能理解 如果朋友一直勸自己吃，本人從愛護動物和環保角度解釋的。小動物被殺多可憐呀，沒有買賣就沒有殺害 當然由於自身消化不好，...