在一份合同上單獨寫一句話-tft每日頭條

在一份合同上單獨寫一句話?What is a correct program? One that does no more and no less than it claims to do.，下面我們就來聊聊關于在一份合同上單獨寫一句話?接下來我們就一起去了解一下吧!

在一份合同上單獨寫一句話

今天這一章叫Design by Contract（DBC）契約設計，我看了一半。說的是，在人類社會，我們會通過合同這種東西來規定雙方的權利和義務，以及如果違反條款的後果。這一項機制也可以引入程序中。

What is a correct program? One that does no more and no less than it claims to do.

什麼是一個正确的程序？一個不比它所聲稱要的多做或少做的程序。

Documenting and verifying that claim is the heart of Design by Contract (DBC, for short).

記錄和驗證這一聲稱，是契約設計（簡稱DBC）的核心。

每個方法都有做些事情，在它做這些事情的之前，他們會對當前的環境有所期待，最主要的期待就是輸入參數。在它做完事情之後，也需要像它聲稱的那樣，返回相應的數據。它的發明者把它們稱為前置條件（Preconditions）與後置條件（Postconditions）。主要說說前置條件吧。作者特别舉了一個例子來說明責任的歸屬。假如有一個除法方法divide()，那檢查前置條件的認為是調用者還是divide()内部？答案是都不是，前置條件在他們中間，divide()默認所有參數都是正确的，所以驗證的責任應該由調用者來承擔。在傳給divide()之前就完成檢查。假如不小心把0傳給了被除數，那可以抛異常、可以讀取其他的數值，可以打印錯誤、可以直接結束程序……幹什麼都可以，但是不能把它傳給divide()方法。在之前正交性那一章中作者提到，建議我們編寫“害羞的（shy）”代碼。隻管好自己的事，手不要伸太長，不要與其他部分有過多的勾連。這一章契約設計強調的是要寫“懶惰的（lazy）”代碼，嚴格規定你想要接受什麼，并盡可能少的承諾返回的内容。如果不對輸入值做任何限制，并承諾會返回“整個世界”，那意味着你有一大堆代碼要寫。因為你要考慮所有情況，并作出相應的調整，否則就可能會出現一些意想不到的異常情況。比如，程序原本隻能處理10位數字，但是調用者傳入了11位數字，就可能造成結果錯誤，或者程序直接運行失敗。邊界往往是最容易出問題的地方，所以最好在一開始就規定清楚。就像常說的那句話“醜話說前面”，規矩在一開始就定好了，之後也可以有法可依。執行人可以更清晰明确地執行，執法者也可以名正言順地進行處理。

字數：667

耗時：50分

··················END··················