我已閱讀了所有這些方法：合同設計，面向方面編程，測試驅動開發和單元測試。在實踐中，我只使用單元測試和AOP（AspectJ）。我知道這是不同的事情，但似乎我對他們的目的有一些妄想。DBC，AOP，TDD和單元測試目標之間的差異
問題\索取：您可以爲DBC，AOP，TDD的目的和單元測試之間的差異一個簡短的調查？你能回顧一下我的結論並指出我錯在哪裏嗎？
我的結論：
IMMO DBC，TDD和AOP沒有直接的可比性，是具有非常不同的目的完全不同的事情，我試圖解釋一下這個技術是我個人的看法：
DBC目的其定義語義（以前置條件，後置條件和不變量的形式）以確保一段代碼的正確性。根據DBC的實現，這些合約可以在運行時斷言，或者可以在編譯時嘗試執行。老實說，我不得不說，我從來沒有使用過，我從來沒有看到一個真正的DBC系統構建，沒有DBC的良好工具支持，並且在使用DBC方面很少有實際的建議。 TDD其關於通過使用示例（又稱測試）來確保正確性，以及TDD其使用快速反饋週期紅綠重構的設計技術。與DBC一樣，它也是一種無缺陷構建軟件的技術，但採用了一種非常不同的方法。我在很多項目中使用TDD超過六年（或多一點我不記得），對我而言，它現在是開發軟件的「自然」方式，當然這是個人選擇而非一般建議，自己嘗試。
AOP它的另一個截然不同的東西，它是一種處理交叉擔憂的方法，你可以用它來驗證合同的強制執行情況嗎？，可能是的，但是這不能超過其中一個無限用途AOP。只有我的觀點，我不是AOP的忠實粉絲，我必須用很多AOP的東西來維護遺留的代碼庫，而IMMO AOP是一個非常複雜的方式來隱藏系統的重要功能。
我要在此一刺...
DBC - 這是一個編程方法，這種方法比較容易在與防禦式編程對比了解。
設計按合同有關規定全面誰（客戶端功能或功能提供商）是負責什麼（合同）。功能提供商承諾：如果您符合我的先決條件（例如輸入值爲非負值），然後我保證我的後置條件（例如，然後我將返回值的平方根）。一個同樣有效的合同是：如果你給我任何數字（沒有先決條件），那麼如果它是否定的，我會返回-1，否則我將返回數字的平方根。
使用這種方法，功能客戶端顯然負責檢查在調用功能前滿足前提條件。功能提供者可以自由地假定符合前提條件，但必須確保符合其後置條件。
將此與防禦性編程進行對比，其中特徵客戶端和功能提供者將驗證數據以防萬一另一個不會。
DBC試圖幫助開發人員通過降低其複雜性（更強的規格和更少的重複代碼）來創建正確的代碼。
如何實現DBC是排序的實現細節。您可以在沒有任何工具支持的情況下完成DBC，只需在紙上定義API並實施它，以便客戶檢查（指定）前置條件並且提供商符合其後置條件（適用於所有有效的前提條件）。當然，工具支持幫助....
單元測試是一個簡單的方式，以確保您的代碼行爲與您的預期（其中一數）。您可以對DBC代碼或非DBC代碼使用單元測試。單元測試和DBC在某種程度上是互補的，因爲它很容易爲定義良好的API規範編寫單元測試;另一方面，如果您使用工具來支持DBC，則甚至可能會看到它們是重複的，因爲合同可能最終會在單元測試和DBC工具中進行描述/驗證。
TDD是另一種降低從不同角度開發代碼的複雜性的方法。從功能規格開始，爲其編寫測試（它應該失敗），編寫使測試通過的生產代碼（而不是更多）。 TDD代碼仍然可以使用DBC（或不）。
AOP更像是一種技術 - 它是讓代碼運行到你想要的位置的一種替代方法。它可以用來支持很多事情，但我不會說「AOP是包含DBC的更廣泛的概念」，不僅僅是我認爲筆是一個比短篇小說更廣泛的概念。
那麼DBC優於單元測試的優點是什麼？ –
對我而言，沒有任何優勢，DBC就像是一個永不履行的承諾，TDD是現在很多程序員都在實踐中取得卓越成果的現實。 – AlfredoCasado