摘要：程序失敗時(shí)，很難確定錯(cuò)誤的位置。它保護(hù)客戶免受單位工作細(xì)節(jié)的影響。將前提條件放在中，并將后置條件放入和。涉及可變對象的契約現(xiàn)在取決于每個(gè)引用可變對象的每個(gè)人的良好行為。設(shè)計(jì)規(guī)約按規(guī)約分類比較規(guī)約它是如何確定性的。

1.編程語言中的功能/方法
2.規(guī)約：便于交流的編程，為什么需要規(guī)約
行為等同規(guī)約結(jié)構(gòu)：前提條件和后條件測試和驗(yàn)證規(guī)約
3.設(shè)計(jì)規(guī)約分類規(guī)約圖表規(guī)約質(zhì)量規(guī)約
4.總結(jié)

方法：構(gòu)建模塊
大型項(xiàng)目由小型方法構(gòu)建?
方法可以多帶帶開發(fā)，測試和重復(fù)使用
方法的用戶不需要知道它是如何工作的 - 這被稱為“抽象”

注意：調(diào)用方法時(shí)參數(shù)類型不匹配 - 靜態(tài)檢查
返回值類型是否匹配，也在靜態(tài)類型檢查階段完成

（1）編程中的文檔

Java API文檔：一個(gè)例子
類層次結(jié)構(gòu)和實(shí)現(xiàn)的接口列表。?
直接子類，并為接口實(shí)現(xiàn)類。?
類的描述?
構(gòu)建思想?
方法摘要列出了我們可以調(diào)用的所有方法
每個(gè)方法和構(gòu)造函數(shù)的詳細(xì)描述

方法簽名：我們看到返回類型，方法名稱和參數(shù)。 我們也看到例外。 目前，這些通常意味著該方法可能遇到的錯(cuò)誤。

完整的描述。

參數(shù)：方法參數(shù)的描述。

以及該方法返回的描述。

記錄假設(shè)

向下寫入變量的類型記錄了一個(gè)關(guān)于它的假設(shè)：例如，此變量將始終引用一個(gè)整數(shù)。

Java實(shí)際上在編譯時(shí)檢查了這個(gè)假設(shè)，并保證在你的程序中沒有地方違反了這個(gè)假設(shè)。

聲明一個(gè)變量final也是一種形式的文檔，聲明該變量在初始賦值后永遠(yuǎn)不會改變。

Java也會靜態(tài)地檢查它。

如何函數(shù)/方法的假設(shè)？

便于交流的編程

為什么我們需要寫下我們的假設(shè)？

因?yàn)榫幊坛錆M了它們，如果我們不寫下它們，我們將不會記住它們，而其他需要閱讀或更改我們程序的人將不會知道它們。 他們必須猜測。

程序必須記住兩個(gè)目標(biāo)：

與電腦交流。 首先說服編譯器你的程序是合理的 - 語法正確和類型正確。 然后讓邏輯正確，以便在運(yùn)行時(shí)提供正確的結(jié)果。

與其他人溝通。 使程序易于理解，以便在有人修復(fù)，改進(jìn)或未來適應(yīng)時(shí)，他們可以這樣做。

黑客與工程

黑客往往以肆無忌憚的樂觀為標(biāo)志

不好：在測試任何代碼之前先寫很多代碼

不好：把所有的細(xì)節(jié)都留在腦海中，假設(shè)你會永遠(yuǎn)記住它們，而不是寫在你的代碼中

不好：假設(shè)錯(cuò)誤不存在或者很容易找到并修復(fù)

但軟件工程不是黑客行為。 工程師是悲觀主義者：

好：一次寫一點(diǎn)，隨時(shí)測試（第7章中的測試優(yōu)先編程）。

好：記錄你的代碼依賴的假設(shè)

好：捍衛(wèi)你的代碼免受愚蠢 - 尤其是你自己的！

靜態(tài)檢查有助于此

（2）規(guī)約和契約（方法）

規(guī)約（或稱為契約）
規(guī)約是團(tuán)隊(duì)合作的關(guān)鍵。 沒有規(guī)約就不可能委托實(shí)施方法的責(zé)任。
規(guī)約作為一種契約：實(shí)施者負(fù)責(zé)滿足契約，而使用該方法的客戶可以依賴契約。

說明方法和調(diào)用者的責(zé)任

定義實(shí)現(xiàn)的正確含義

規(guī)約對雙方都有要求：當(dāng)規(guī)約有先決條件時(shí)，客戶也有責(zé)任。

如果你在這個(gè)時(shí)間表上支付了這筆款項(xiàng)......

我將用下面的詳細(xì)規(guī)約來構(gòu)建一個(gè)

有些契約有不履行的補(bǔ)救措施

為什么規(guī)約？

現(xiàn)實(shí)：

程序中最常見的錯(cuò)誤是由于對兩段代碼之間的接口行為的誤解而產(chǎn)生的。

盡管每個(gè)程序員都有規(guī)約說明，但并不是所有的程序員都把它們寫下來。 因此，團(tuán)隊(duì)中的不同程序員有不同的規(guī)約。

程序失敗時(shí)，很難確定錯(cuò)誤的位置。

優(yōu)點(diǎn)：

代碼中的精確規(guī)約讓您分?jǐn)偞a片段的責(zé)備，并且可以免除您在修復(fù)應(yīng)該去的地方令人費(fèi)解的痛苦。

規(guī)約對于一個(gè)方法的客戶來說是很好的，因?yàn)樗麄儾恍枰喿x代碼。

規(guī)約對于方法的實(shí)現(xiàn)者來說是很好的，因?yàn)樗麄兘o了實(shí)現(xiàn)者自由地改變實(shí)現(xiàn)而不告訴客戶。
規(guī)約也可以使碼代碼更快。
契約充當(dāng)客戶和實(shí)施者之間的防火墻。

它保護(hù)客戶免受單位工作細(xì)節(jié)的影響。

它將執(zhí)行器從單元使用的細(xì)節(jié)中屏蔽掉。

這種防火墻會導(dǎo)致解耦，允許單元的代碼和客戶端的代碼獨(dú)立更改，只要這些更改符合規(guī)約。

解耦，不需要了解具體實(shí)現(xiàn)

對象與其用戶之間的協(xié)議

方法簽名（型號規(guī)約）

功能和正確性預(yù)期

性能預(yù)期性能?

該方法做了什么，而不是如何做

接口（API），不是實(shí)現(xiàn)

（3）行為等價(jià)性

要確定行為等同性，問題是我們是否可以用另一個(gè)實(shí)現(xiàn)替代另一個(gè)實(shí)現(xiàn)
等價(jià)的概念在客戶眼中。

為了使一個(gè)實(shí)現(xiàn)替代另一個(gè)實(shí)現(xiàn)成為可能，并且知道何時(shí)可以接受，我們需要一個(gè)規(guī)約來說明客戶端依賴于什么
注意：規(guī)約不應(yīng)該談?wù)摲椒惖木植孔兞炕蚍椒惖乃接凶侄巍?/p>

（4）規(guī)約結(jié)構(gòu)：前提條件和后置條件

一個(gè)方法的規(guī)約由幾個(gè)子句組成：

先決條件，由關(guān)鍵字require表示

后置條件，由關(guān)鍵字效果表示

特殊行為：如果違反先決條件，會發(fā)生什么？

先決條件是客戶（即方法的調(diào)用者）的義務(wù)。 這是調(diào)用方法的狀態(tài)。
后置條件是該方法實(shí)施者的義務(wù)。
如果前提條件適用于調(diào)用狀態(tài)，則該方法必須遵守后置條件，方法是返回適當(dāng)?shù)闹担瑨伋鲋付ǖ漠惓?，修改或不修改對象等等?/p>

整體結(jié)構(gòu)是一個(gè)合乎邏輯的含義：如果在調(diào)用方法時(shí)前提條件成立，則在方法完成時(shí)必須保持后置條件。
如果在調(diào)用方法時(shí)前提條件不成立，則實(shí)現(xiàn)不受后置條件的限制。

可以自由地做任何事情，包括不終止，拋出異常，返回任意結(jié)果，進(jìn)行任意修改等。

Java中的規(guī)約

Java的靜態(tài)類型聲明實(shí)際上是方法的前提條件和后置條件的一部分，該方法是編譯器自動(dòng)檢查和執(zhí)行的一部分。
靜態(tài)檢查
契約的其余部分必須在該方法之前的評論中進(jìn)行描述，并且通常取決于人類對其進(jìn)行檢查并予以保證。
參數(shù)由@param子句描述，結(jié)果由@return和@throws子句描述。
將前提條件放在@param中，并將后置條件放入@return和@throws。

可變方法的規(guī)約

如果效應(yīng)沒有明確說明輸入可以被突變，那么我們假設(shè)輸入的突變是隱式地被禁止的。
幾乎所有的程序員都會承擔(dān)同樣的事情。 驚喜突變導(dǎo)致可怕的錯(cuò)誤。
慣例：

除非另有說明，否則不允許突變。

沒有突變的投入

可變對象可以使簡單的規(guī)約/合約非常復(fù)雜
可變對象降低了可變性

可變對象使簡單的合約變得復(fù)雜

對同一個(gè)可變對象（對象的別名）的多次引用可能意味著程序中的多個(gè)地方 - 可能相當(dāng)分散 - 依靠該對象保持一致。
按照規(guī)約說明，契約不能再在一個(gè)地方執(zhí)行，例如， 一個(gè)類的客戶和一個(gè)類的實(shí)施者之間。
涉及可變對象的契約現(xiàn)在取決于每個(gè)引用可變對象的每個(gè)人的良好行為。

作為這種非本地契約現(xiàn)象的一個(gè)癥狀，考慮Java集合類，這些類通常記錄在客戶端和實(shí)現(xiàn)者之間的非常明確的契約中。

嘗試找到它在客戶端記錄關(guān)鍵要求的位置，以便在迭代時(shí)無法修改集合。

對這樣的全局屬性進(jìn)行推理的需要使得理解難度更大，并且對可變數(shù)據(jù)結(jié)構(gòu)的程序的正確性有信心。
我們?nèi)匀槐仨氝@樣做 - 為了性能和便利性 - 但是為了這樣做，我們在bug安全方面付出了巨大的代價(jià)。

可變對象降低了可變性

可變對象使得客戶端和實(shí)現(xiàn)者之間的契約更加復(fù)雜，并且減少了客戶端和實(shí)現(xiàn)者改變的自由。
換句話說，使用允許更改的對象會使代碼難以改變。

（5）*測試和驗(yàn)證規(guī)約

正式契約規(guī)約

Java建模語言（JML）
這是一個(gè)有優(yōu)勢的理論方法

運(yùn)行時(shí)檢查自動(dòng)生成

正式驗(yàn)證的依據(jù)

自動(dòng)分析工具

缺點(diǎn)

需要很多工作

在大的不切實(shí)際

行為的某些方面不符合正式規(guī)約

文本說明 - Javadoc

實(shí)用方法
記錄每個(gè)參數(shù)，返回值，每個(gè)異常（選中和未選中），該方法執(zhí)行的操作，包括目的，副作用，任何線程安全問題，任何性能問題。
不要記錄實(shí)施細(xì)節(jié)

語義正確性遵守契約

編譯器確保類型正確（靜態(tài)類型檢查）

防止許多運(yùn)行時(shí)錯(cuò)誤，例如“未找到方法”和“無法將布爾值添加到int”

靜態(tài)分析工具（如FindBugs）可以識別許多常見問題（錯(cuò)誤模式）

例如：覆蓋equals而不覆蓋hashCode

但是，如何確保語義的正確性？

正式驗(yàn)證

使用數(shù)學(xué)方法證明正式規(guī)約的正確性?
正式證明一個(gè)實(shí)現(xiàn)的所有可能的執(zhí)行符合規(guī)約?
手動(dòng)努力; 部分自動(dòng)化; 不能自動(dòng)確定

測試

使用受控環(huán)境中的選定輸入執(zhí)行程序?
目標(biāo)

顯示錯(cuò)誤，因此可以修復(fù)（主要目標(biāo)）

評估質(zhì)量

明確說明書，文件

黑盒測試：以獨(dú)立于實(shí)現(xiàn)的方式檢查測試的程序是否遵循指定的規(guī)約。

（1）按規(guī)約分類

比較規(guī)約

它是如何確定性的。 該規(guī)約是否僅為給定輸入定義了單個(gè)可能的輸出，或允許實(shí)現(xiàn)者從一組合法輸出中進(jìn)行選擇？
它是如何聲明的。 規(guī)約是否只是表征輸出的結(jié)果，還是明確說明如何計(jì)算輸出？
它有多強(qiáng)大。 規(guī)約是否只有一小部分法律實(shí)施或一大套？
“什么使一些規(guī)約比其他規(guī)約更好？”

如何比較兩種規(guī)約的行為來決定用新規(guī)約替換舊規(guī)約是否安全？

規(guī)約S2強(qiáng)于或等于規(guī)約S1如果

S2的先決條件弱于或等于S1

對于滿足S1的先決條件的狀態(tài)，S2的后置條件強(qiáng)于或等于S1。

那么滿足S2的實(shí)現(xiàn)也可以用來滿足S1，在程序中用S2代替S1是安全的。

規(guī)則：

削弱先決條件：減少對客戶的要求永遠(yuǎn)不會讓他們感到不安。

加強(qiáng)后續(xù)條件，這意味著做出更多的承諾。

如果S3既不強(qiáng)于也不弱于S1，則規(guī)約可能會重疊（因此存在僅滿足S1，僅S3，以及S1和S3的實(shí)現(xiàn)）或者可能不相交。
在這兩種情況下，S1和S3都是無法比較的。

（2）圖表規(guī)約

這個(gè)空間中的每個(gè)點(diǎn)代表一個(gè)方法實(shí)現(xiàn)。
規(guī)約在所有可能的實(shí)現(xiàn)的空間中定義了一個(gè)區(qū)域。
一個(gè)給定的實(shí)現(xiàn)要么按照規(guī)約行事，要滿足前置條件 - 隱含 - 后置契約（它在區(qū)域內(nèi)），或者不（在區(qū)域外）。
實(shí)現(xiàn)者可以自由地在規(guī)約中移動(dòng)，更改代碼而不用擔(dān)心會破壞客戶端。
這對于實(shí)現(xiàn)者能夠提高其算法的性能，代碼的清晰度或者在發(fā)現(xiàn)錯(cuò)誤時(shí)改變他們的方法等而言是至關(guān)重要的。
客戶不知道他們會得到哪些實(shí)現(xiàn)。

他們必須尊重規(guī)約，但也有自由改變他們?nèi)绾问褂脤?shí)現(xiàn)而不用擔(dān)心會突然中斷。

當(dāng)S2比S1強(qiáng)時(shí)，它在此圖中定義了一個(gè)較小的區(qū)域。
較弱的規(guī)約定義了一個(gè)更大的區(qū)域。
強(qiáng)化實(shí)施者的后置條件意味著他們自由度較低，對產(chǎn)出的要求更強(qiáng)。
弱化前提意味著：實(shí)現(xiàn)必須處理先前被規(guī)約排除的新輸入。

（3）設(shè)計(jì)好的規(guī)約
規(guī)約的質(zhì)量

什么是一個(gè)好方法？ 設(shè)計(jì)方法意味著主要編寫一個(gè)規(guī)約。
關(guān)于規(guī)約的形式：它顯然應(yīng)該簡潔，清晰，結(jié)構(gòu)良好，以便閱讀。
然而，規(guī)約的內(nèi)容很難規(guī)定。 沒有一個(gè)可靠的規(guī)則，但有一些有用的指導(dǎo)方針。

規(guī)約應(yīng)該是連貫的（內(nèi)聚的）

該規(guī)約不應(yīng)該有很多不同的情況。 冗長的參數(shù)列表，深層嵌套的if語句和布爾型標(biāo)志都是麻煩的跡象。
除了可怕地使用全局變量和打印而不是返回之外，規(guī)約不是一致的 - 它執(zhí)行兩個(gè)不同的事情，計(jì)算單詞并找出最長的單詞。
調(diào)用的結(jié)果應(yīng)該是信息豐富的
如果返回null，則無法確定密鑰是否先前未綁定，或者實(shí)際上是否綁定為null。這不是一個(gè)很好的設(shè)計(jì)，因?yàn)榉祷刂凳菬o用的，除非您確定沒有插入null。

規(guī)約應(yīng)該足夠強(qiáng)大

規(guī)約應(yīng)給予客戶在一般情況下足夠強(qiáng)大的保證 - 它需要滿足其基本要求。 - 在規(guī)定特殊情況時(shí)，我們必須格外小心，確保它們不會破壞本來是有用的方法。例如，對于一個(gè)不合理的論證拋出異常，但允許任意的突變是沒有意義的，因?yàn)榭蛻舳藢o法確定實(shí)際發(fā)生了什么樣的突變。

規(guī)約也應(yīng)該足夠薄弱

這是一個(gè)不好的規(guī)約。

它缺少重要的細(xì)節(jié)：打開閱讀或?qū)懽魑募?它是否已經(jīng)存在或被創(chuàng)建？

它太強(qiáng)大了，因?yàn)樗鼰o法保證打開文件。 它運(yùn)行的過程可能缺少打開文件的權(quán)限，或者文件系統(tǒng)可能存在一些超出程序控制范圍的問題。相反，說明書應(yīng)該說更弱一些：它試圖打開一個(gè)文件，如果成功，文件具有某些屬性。

規(guī)約應(yīng)該使用抽象類型

用抽象類型編寫我們的規(guī)約為客戶和實(shí)現(xiàn)者提供了更多的自由。
在Java中，這通常意味著使用接口類型，如Map或Reader，而不是像HashMap或FileReader這樣的特定實(shí)現(xiàn)類型。

像列表或集合這樣的抽象概念

特定的實(shí)現(xiàn)像ArrayList或HashSet。

這強(qiáng)制客戶端傳入一個(gè)ArrayList，并強(qiáng)制實(shí)現(xiàn)返回一個(gè)ArrayList，即使可能存在他們希望使用的替代List實(shí)現(xiàn)。

先決條件還是后置條件？

是否使用前提條件，如果是，則在繼續(xù)之前，方法代碼是否應(yīng)該嘗試確保先決條件已滿足？
對于程序員：

前提條件最常見的用法是要求提供一個(gè)屬性，因?yàn)樵摲椒z查該屬性會很困難或昂貴。

如果檢查一個(gè)條件會使方法變得難以接受，那么通常需要一個(gè)先決條件。

對用戶而言：

一個(gè)不平凡的先決條件會給客戶帶來不便，因?yàn)樗麄儽仨毚_保他們不會以不良狀態(tài)調(diào)用該方法（違反前提條件）; 如果他們這樣做，沒有可預(yù)測的方法來從錯(cuò)誤中恢復(fù)。

所以方法的用戶不喜歡先決條件。

因此，Java API類傾向于指定（作為后置條件），當(dāng)參數(shù)不合適時(shí)，它們會拋出未經(jīng)檢查的異常。

這使得在調(diào)用者代碼中找到導(dǎo)致傳遞錯(cuò)誤參數(shù)的錯(cuò)誤或不正確的假設(shè)更容易。

通常情況下，盡可能靠近錯(cuò)誤的地點(diǎn)快速失敗，而不是讓糟糕的價(jià)值觀通過遠(yuǎn)離其原始原因的程序傳播。

關(guān)鍵因素是檢查的費(fèi)用（編寫和執(zhí)行代碼）以及方法的范圍。

如果只在類本地調(diào)用，則可以通過仔細(xì)檢查調(diào)用該方法的所有類來解決前提條件。
如果該方法是公開的，并且被其他開發(fā)人員使用，那么使用前提條件將不太明智。 相反，像Java API類一樣，您應(yīng)該拋出一個(gè)異常。

總結(jié)
規(guī)約作為程序?qū)崿F(xiàn)者與其客戶之間的關(guān)鍵防火墻。
它使得多帶帶的開發(fā)成為可能：客戶端可以自由地編寫使用該過程的代碼，而無需查看其源代碼，并且實(shí)現(xiàn)者可以自由地編寫實(shí)現(xiàn)該過程的代碼而不知道它將如何使用。

減少錯(cuò)誤保證安全

一個(gè)好的規(guī)約清楚地記錄了客戶和實(shí)施者依賴的相互假設(shè)。錯(cuò)誤通常來自界面上的分歧，并且規(guī)約的存在會降低這一點(diǎn)。

在你的規(guī)約中使用機(jī)器檢查的語言特性，比如靜態(tài)類型和異常，而不僅僅是一個(gè)人類可讀的評論，可以更多地減少錯(cuò)誤。容易理解

一個(gè)簡短的規(guī)約比實(shí)現(xiàn)本身更容易理解，并且使其他人不必閱讀代碼。

準(zhǔn)備好改變

規(guī)約在代碼的不同部分之間建立契約，允許這些部分獨(dú)立更改，只要它們繼續(xù)滿足合同的要求。

聲明性規(guī)約在實(shí)踐中是最有用的。
先決條件（削弱了規(guī)約）使客戶的生活更加艱難，但明智地應(yīng)用它們是軟件設(shè)計(jì)師的重要工具，允許實(shí)施者做出必要的假設(shè)。

減少錯(cuò)誤保證安全

沒有規(guī)約，即使是我們程序中任何部分的細(xì)微變化，都可能成為敲打整個(gè)事情的尖端多米諾骨牌。

良好的結(jié)構(gòu)，一致的規(guī)約最大限度地減少了誤解，并最大限度地提高了我們在靜態(tài)檢查，謹(jǐn)慎推理，測試和代碼審查的幫助下編寫正確代碼的能力。

容易理解

寫得很好的聲明性規(guī)約意味著客戶端不必閱讀或理解代碼。

準(zhǔn)備好改變

適當(dāng)?shù)囊?guī)約賦予實(shí)現(xiàn)者自由，適當(dāng)?shù)膹?qiáng)壯規(guī)約賦予客戶自由。

我們甚至可以自己改變規(guī)約，而不必重新審視每個(gè)地方的使用情況，只要我們只是加強(qiáng)它們：削弱先決條件并加強(qiáng)后置條件。