契約式設計可以理解為正則程式設計的一種實踐：
如果用我的三腳貓能力將這種實踐方法形式化的話，大致如下（如有不正確處，請不吝指正）：
1、對於方法method的precondition & postcondition：
function(regularmthod) =
^ regularfunction
^ general-class-method
^assert(precondition)
^assert(postcondition);
=> f1( f2 )
|-> assert(f2.precondition) => assert( f1.postcondition )
當所有方法都滿足上述條件的時候，那就意味著該程式的輸入如果滿足assert(precondition)，那麼它的輸出也滿足assert(postcondition)，從而在邏輯上保證程式的正確性。這是針對方法呼叫或者函式呼叫上講的，這個倒是可以在有函式或者過程的語言裡面都可以實現。我個人理解為operation組合上的正則性（regularity）。
2、類class的不變式invariant:
class(invariantclass) =
^ general-class
^ invariant : assert(invariant) when any method called.
乙個類的所有直接或者間接的子類都要滿足它的不變式invariant，從而保證該類及其衍生類在資料上保證正確性，個人理解為data組合的正則性。
綜合上述兩點，在operation 以及 data的組合上均實現了正則性，即物件導向上的正則性，從而在理論上保證了物件的正則性以及以物件構造出來的程式的正確。
3、適當的dbc
過猶不及。如果我們將每乙個類都很詳細地進行dbc，那也是一件很耗時、痛苦的沒有必要的事情，正如你預防著小偷固然好，但是將除了自己之外的其他人都像防賊一樣來防著也不合適一樣。我們應該是適當地dbc。
dbc更是一種思想，一種思維模式，為如何構造出高質量的軟體指出乙個道道來，它告訴我們，依如是法，達高質量的彼岸。如果在實踐中運用則應當根據具體情況而定。
引入契約式設計
契約式設計規定方法應該對輸入和輸出進行驗證，這樣你便可以保證你得到的資料是可以工作的，一切都是按預期進行的，如果不是按預期進行，異常或是錯誤就應該被返回，下面我們舉的例子中，我們方法中的引數可能會值為null的情況，在這種情況下由於我們沒有驗證，nullreferenceexception異常會報出...
契約式程式設計
契約是減少大型專案成本的突破性技術。契約由先驗條件 後驗條件 錯誤和不變數等概念組成。契約可以而加到 c 中而無需對語言加以改造，但是卻十分笨拙且不一致。在語言內部支援契約的目的是 給契約乙個一致的觀感 提供工具支援 使編譯器能夠根據從契約中收集的資訊生成更好的 易於管理並強制實行契約 處理契約繼承...
Design by Contract（契約式設計）
design by contract 是bertrand meyer 總結的一項設計技巧 design by contract 的核心是斷言 assertion 所謂 斷言 是指永遠為真的布林型語句，如果不為真，則程式必然存在錯誤。通常情況下，檢查斷言的時機，應該侷限於除錯 debug 階段，而不是...