Design by Contract編程的最佳實踐是什麼？Design by Contract編程的最佳實踐
在大學裏我學到合同PARADIGMA （在OO環境） 我們學會了三種方式來解決這個問題設計：
1）總體規劃：涵蓋所有可能的特殊情況下，在其 效果（參考數學）
2）名義規劃：只有在滿足前提條件時'承諾'正確的效果。 （否則影響是不確定的）
3）防禦性編程：使用異常信號的方法
現在非法調用，我們在不同的場景OO都集中在每種情況下的正確使用，但我們還沒有學會什麼時候使用WHICH ... （主要是練習練習的策略..）
現在我覺得很奇怪我沒有問過我的老師（但是在課堂上，沒有人問過我）
就我個人而言，我從不使用名義現在，並傾向於取代先決條件（比如我用：拋出IllegalDivisionByZero，而不是說'前提條件：divider應該與零不同），並且只編程總的有意義的東西（所以我不會返回除零的常規值），但是這種方法是隻是基於個人發現和喜好。
所以我問你們：
有沒有什麼最佳實踐？
我不知道這種劃分，而它並沒有真正反映我的經驗的鏜孔循環。
總體規劃幾乎是不可能的。你無法保證你涵蓋所有特殊情況。所以基本上你應該限制你的範圍，並拒絕超出範圍的情況下（這是的前提條件作用）
名義編程不希望。應該禁止未定義的效果。
防禦性編程是必須的。你應該始終表示非法調用方法。
我贊成這個設計完全按合同內容執行，這一點，在我的意見總體規劃
前提條件（一種的實際和affortable版防禦性編程）發出非法調用該方法的信號。儘量限制你的範圍，以便你可以簡化代碼。如果可能的話，通過縮小範圍來避免複雜的實施。
後續條件如果未獲得所需的效果則會產生錯誤。即使是你的錯，你也應該通知來電者你錯過了你的目標。
不變量檢查是否保留了對象一致性。
這一切都歸結爲您希望分配給客戶和合同實施者的責任。
在防禦性編程中，您可以強制實施者檢查在某些情況下可能代價甚至不可能的錯誤情況。想象一下binarySearch指定的合約，例如你的輸入數組必須被排序。運行該算法時無法檢測到這一點。你必須對它進行手動檢查，這實際上會使執行時間增加一個數量級。支持我的意見是從javadocs的方法的簽名。
另一點是People和框架現在傾向於實現異常轉換機制，主要用於將檢查到的異常（防禦風格）轉換爲運行時異常，只有在發生錯誤時纔會彈出。通過這種方式，合同的客戶和執行者在處理彼此時不必擔心。
再次，這是我的個人意見，僅以我有限的經驗爲後盾，我很想聽到更多關於此主題的內容。
...但我們還沒有學會何時 使用哪個...
我認爲最好的做法是要「防禦性越好」。你的運行時是否可以檢查。正如@MahdeTo有時提到，由於性能原因這是不可能的;在這種情況下會回落到未定義或不令人滿意的行爲。
這就是說，在你的文檔中明確什麼是運行時檢查，什麼不是。
像許多計算「它取決於」可能是最好的答案。
設計，通過合同契約/編程可以通過顯式記錄的條件的功能幫助開發很大。只要文檔可以成爲幫助，甚至無需編入（編譯）代碼。
在可行的情況下，我建議防禦 - 檢查每個條件。但只適用於開發和調試版本。這樣，當條件被破壞時，大多數無效假設都會被捕獲。良好的構建系統可以讓您在模塊或文件級別以及全局範圍內打開和關閉不同的條件類型。
在軟件發行版本所採取的行動則取決於系統的條件是如何觸發（內部和外部接口之間通常的區別）。發行版本可以是「總體規劃」 - 所有條件得到一個確定的結果（可以包括錯誤或NaN）
對我來說，「名義編程」是在現實世界中是死路一條。你認爲如果你傳遞了正確的值（這當然是你做的），那麼你收到的價值是好的。如果你的假設是錯誤的 - 你會失敗。
我認爲測試驅動編程就是答案。在實際執行模塊之前，您首先要創建一個單元測試（稱之爲合同）。然後逐步實施功能，並確保合同在您離開時仍然有效。通常我從簡單的存根和模型開始，然後逐漸填充其餘部分，用真正的東西代替刺。繼續改進並使測試更加強大。最後，你最終得到了一個強大的模塊實現，並且你已經有了一個夢幻般的測試平臺 - 合同執行。稍後，如果有人修改模塊，首先看看它是否仍然適合測試牀。如果沒有，合同就會中斷 - 拒絕更改。或者，合同已經過時， - 修正單元測試。等..軟件開發:)
您可以檢查任何數組是否被排序爲先決條件。我們在C++中用斷言來做到這一點。 – 2009-04-13 20:31:01
檢查整個數組是否需要比實際進行二進制搜索更多的時間:) – MahdeTo 2009-04-13 20:38:59
只是一些想法：你可以檢查前提條件只在某些模式下，比如單元測試否？ 進一步的前提條件可以說明，沒有測試，當然 – Peter 2009-04-13 20:59:36