dbc 元素
先驗條件:針對方法（method），它規定了在呼叫該方法之前必須為真的條件。
後驗條件:也是針對方法，它規定了方法順利執行完畢之後必須為真的條件。
不變式:針對整個類，它規定了該類任何例項呼叫任何方法都必須為真的條件。
dbc
六大原則
區分命令和查詢
將基本查詢同派生查詢區分開
針對每個派生查詢，設定乙個後驗條件，使用乙個或多個基本查詢的結果來定義它。
對於每個命令都撰寫乙個後驗條件，規定每個基本查詢的值。
對於每個查詢和命令，採用乙個合適的先驗條件。
撰寫不變式來定義物件的恆定特性
dbc
六大準則
在適當的地方新增物理限制。
先驗條件中盡可能使用高效的查詢。
用不變式限定屬性。
為了支援特性的重定義，用相應的先驗條件確保每個後驗條件。
將預期發生的變化和框定規則這兩種不同的限制分別放置在不同的類中。
有保密性要求，則違背保密性的查詢可以在契約中使用，然後被設為私有屬性。
eiffel中的「契約」
契約關係的雙方是平等的，對整個bussiness的順利進行負有共同責任，沒有哪一方可以只享有權利而不承擔義務。
契約關係經常是相互的，權利和義務之間往往是互相**在一起的；
執行契約的義務在我，而核查契約的權力在人；
我的義務保障的是你的利益，而你的義務保障的是我的利益；
我的看法
不管是不變式，還是先驗後驗條件，都是為了詳細定義元件或物件的狀態，這是為了防止程式設計師懶惰造成產品質量下降而強加的框架。
執行起來有難度的是，使用者在使用元件的時候，即使知道契約，能否嚴格按照契約來做，開發期間是否能夠將所有的違反契約的地方全部列出來，仍然是乙個問題。
所以說是「design by contract」，因為詳盡的測試還是必不可少的。
在ooa，ood，oop中，dbc只是提供了ood的一種思想，是設計元件介面的一般性的原則
程式設計中的完備性
乙個元件的介面構成乙個完備的空間，基本查詢就是其中的基向量，派生查詢可能很多，但都可以由基向量的組合來表示。基向量的所以組合構成這個元件的允許狀態空間
命令能夠改變元件的狀態，使元件從狀態空間中的一點遷移到另外乙個點
簡化介面的複雜性，重要的一點就是減少元件狀態空間的大小，可以通過減少基向量的數目或者減少某個基向量的取值範圍。
精確性和細節 設計階段要求忽略細節，但也同樣丟失了精確性，dbc要求保留模型語義的精確性，避免了設計者和編碼人員之間或者使用者和提供者直接的理解誤差 契約的應用層次也可以覆蓋從設計到編碼以至於測試。在設計階段，了解dbc的人至少不會忽略對違反契約情況的處理，而對這一點缺乏足夠的認識是很多產品不夠健壯的主因。
Design by Contract（契約式設計）
design by contract 是bertrand meyer 總結的一項設計技巧 design by contract 的核心是斷言 assertion 所謂 斷言 是指永遠為真的布林型語句，如果不為真，則程式必然存在錯誤。通常情況下，檢查斷言的時機，應該侷限於除錯 debug 階段，而不是...
Design By Contract 契約式設計
契約式設計 design by contract 把類和它的客戶程式之間的關係看作正式的協議，描述雙方的權利和義務。bertrand meyer把它稱作構建物件導向軟體系統方法的核心。契約式設計的提出，主要基於軟體可靠性方面的考慮。可靠性包括正確性和健壯性，正確性指軟體按照需求規格執行的能力，健壯性...
契約式程式設計
契約是減少大型專案成本的突破性技術。契約由先驗條件 後驗條件 錯誤和不變數等概念組成。契約可以而加到 c 中而無需對語言加以改造，但是卻十分笨拙且不一致。在語言內部支援契約的目的是 給契約乙個一致的觀感 提供工具支援 使編譯器能夠根據從契約中收集的資訊生成更好的 易於管理並強制實行契約 處理契約繼承...