[摘自DbC原則與實踐]Design by Contract的六大原則和六大準則

1. Design by Contract的六大原則:

原則1 區分指令和查詢。查詢傳回一個結果，但不改變對象的可見性質。指令改變對象的狀态，但不傳回結果。

原則2 将基本查詢同派生查詢區分開。派生查詢可以用基本查詢來定義。

原則3 針對每個派生查詢，設定一個後驗條件，使用一個或多個基本查詢的結果來定義它。這樣一來，隻要我們知道基本查詢的值，也就能知道派生查詢的值。

原則4 對于每個指令都撰寫一個後驗條件，以規定每個基本查詢的值。結合“用基本查詢定義派生查詢”的原則(原則3)，我們現在已經能夠知道每個指令的全部可視效果。

原則5 對于沒個查詢和指令，采用一個合适的先驗條件。先驗條件限定了客戶調用查詢和指令的時機。

原則6 撰寫不變式來定義對象的恒定特性。類是某種抽象的展現，應當将注意力集中在最重要的屬性上，以建立關于類抽象的正确概念模型。

2. Design by Contract的六大準則:

準則1 在适當的地方添加實體限制。尤其是那些需要限制變量不應該為void的地方。

準則2 先驗條件中盡可能使用高效的查詢。如果有必要，可以增加高效的派生查詢，并在其後驗條件中確定其與較低效的基本查詢之間的等價關系。

準則3 用不變式限定屬性。如果一個派生查詢被實作為一個屬性，則應通過類中不變式的斷言保證它與其他查詢保持一緻。在一個類的開發過程中，通常應該先把斷言檢測的級别設為最進階，使先驗條件、後驗條件和不變式都得到檢測；一旦通過了檢測和測試，一般就可以降低斷言檢測的級别，隻檢測先驗條件，以提過代碼的運作效率。

準則4 為了支援特性的重定義，用相應的先驗條件確定每個後驗條件。這樣就允許在子類開發過程中進行各種不可預見的重定義。

準則5 将預期發生的變化和框定規則這兩種不同的限制分别放置在不同的類中。這使開發者在擴充已有類時享有更多的自由。

準則6 若有保密性要求，則違背保密性的查詢隻能被設為私有熟悉在契約中使用。這裡的“設為私有”，是對“在契約中使用了該查詢的類”之下的層次而言，至于類之上的層次，這個查詢當然是可以使用的。

本文轉自Silent Void部落格園部落格，原文連結：http://www.cnblogs.com/happyhippy/archive/2006/12/18/601303.html，如需轉載請自行聯系原作者