契約式設計6大原則的理解

在《Design by Contract原則與實踐》中，作者定義了契約式設計的6大原則：

區分命令和查詢；

將基本查詢和派生查詢區分開；

針對每個派生查詢，設定一個后驗條件，使用一個或多個基本查詢的結果來定義它；

對于每個命令都撰寫一個后驗條件，規定每個基本查詢的值；

對于每個查詢和命令，采用一個合適的先驗條件；

撰寫不變式來定義對象的恒定特性。

前面5個針對operation層面而言，不論是面向對象也好，面向過程也好，函數式也好，都可以適用。最后1個針對data層面而言，特別適用于面向對象等有著數據的組合的模式。細分下去，前面2點是對于operation對對象狀態的改變的分別，而3、4兩點是后驗條件的原則，第5點是先驗條件的原則。

1、區分命令和查詢

　　根據operation是否改變對象的狀態，將operation分為命令和查詢兩類，這個應該直接在命名上就體現出來，比如查詢應該使用getXXX等，一眼看到就知道這個是查詢，不改變對象狀態，那個是命令，會改變對象狀態。這個分類除了讓我們能一眼就看出operation的特點之外，還是整個DbC在Operation組合的正則性的基礎。如果劃分錯誤，則可能破壞Operation組合的正則性（比如將一個命令操作當成查詢操作來處理）。

2、將基本查詢和派生查詢區分開

　　對查詢進行細分，有的查詢可以有其它查詢組合，有些是不能由其它查詢組合而得的，前者為派生查詢，后者為基本查詢。

　　對于基本查詢，它是不需要后驗條件的，是默認 assert(postcondition) == true的，因為它是原始的，primitive查詢，而派生查詢是由基本查詢組合而成，這中間涉及到了作者的邏輯，需要一個后驗條件，以確保這個邏輯是正確的。

　　因為基本查詢是確定滿足后驗條件的，所以，如果除了基本查詢之外的所有其他operation的后驗條件最終都由基本查詢構成，那么久保證這些operation的后驗條件的正確性和正當性。引申出來就是原則3和原則4:

　　PostCondition(PrimitiveQuery) =

　　　　^ Assert(postcondition) == true

　　PostCondition(ComposedQuery)= PrimitiveQuery{1..n}

　　PostCondition(Command)=PrimitiveQuery{1..n}

　　這就保證了所有operation的后驗條件均是正當的正確的。

3、對于每個查詢和命令，采用一個合適的先驗條件

　　每個真理都是在一定的前提之下才成立的。如果某個查詢操作不需要先驗條件，那么它的先驗條件就是any precondition.

　　這和前面所說的后驗條件結合在一起，保證了Operation的組合的正則性。這里也強調了合適。

4、撰寫不變式來定義對象的恒定特性

　　對象的某些屬性自始至終都是需要滿足某些條件的。仔細地區分地話，我們應該更加關注那些在command operation里面會改變的屬性，確保這些屬性一直滿足這些條件，從而保證data滿足不變式的要求和恒定特性。就C++而言，這點是需要特別留意的，一般建議在子類里面不要直接操作父類成員變量，否則對于保證對象成員變量的恒定特性是很麻煩的，在C++里面還有友元函數，友元類等，建議盡量不要在友元函數、友元類里面修改類成員變量值。對于成員變量的修改建議抽取出一個方法供調用，這樣子，對于保證data的恒定特性非常有必要。

?

轉載于:https://www.cnblogs.com/raison/p/4055454.html

總結

以上是生活随笔為你收集整理的契约式设计（DbC）感想（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。