單元測試
9.1 TDD三定律
- 在編寫不能通過的單元測試前陷遮，不可編寫生產(chǎn)代碼
- 只可編寫剛好無法通過的單元測試滓走，不能編譯也不算通過
- 只可編寫剛好足以通過當(dāng)前失敗測試的生產(chǎn)代碼
9.2 保持測試的整潔
測試代碼和生產(chǎn)代碼一樣重要。他需要被思考帽馋，設(shè)計(jì)和照料
9.3 整潔的測試
測試的要素：整潔性
** 9.3.1 面向特定領(lǐng)域的測試語言 **
面對特定領(lǐng)域的語言搅方。不要直接使用程序員提供的對系統(tǒng)進(jìn)行操作的API，而是打造一套包裝這些API的函數(shù)與工具代碼
** 9.3.2 雙重標(biāo)準(zhǔn) **
有些事在生產(chǎn)環(huán)境中不能夠去做绽族，而在測試環(huán)境中做卻完全沒有問題姨涡。
9.4 每個測試一個斷言
9.5 F.I.R.S.T
F:Fast,測試足夠快能夠快速運(yùn)行
I：Independency，測試應(yīng)該相互獨(dú)立吧慢，彼此沒有聯(lián)系
R：Repeatable涛漂，可以重復(fù)通過
S：Self-Validating，自足驗(yàn)證
T：Timely娄蔼，及時
第十章 類
10.1 類的組織
類應(yīng)該由一組變量列表開始怖喻，如果有公共靜態(tài)變量，應(yīng)該先出現(xiàn)岁诉，然后是私有靜態(tài)變量锚沸，以及私有實(shí)體變量，很少會有公共變量涕癣。
公共函數(shù)應(yīng)該跟在變量列表之后哗蜈。我們喜歡將某個公共函數(shù)調(diào)用的私有工具函數(shù)緊隨在該公共函數(shù)后面。
封裝
我們喜歡保持變量和工具函數(shù)的私有性坠韩，但并不執(zhí)著于此距潘。放松封裝總是下策。
10.2 類應(yīng)該短小
類的大小的衡量只搁，通過權(quán)責(zé)responsibility來判斷 音比。
類的名稱應(yīng)該描述其權(quán)責(zé)，命名是判斷類的長度第一個手段氢惋，如果無法精確命名一個類洞翩，或者類名過長稽犁，很含混，該類越可能含有過多的權(quán)責(zé)骚亿。
10.2.1 單一職責(zé)原則
系統(tǒng)應(yīng)該由許多短小的類而不是少量巨大的類組成已亥。每個小類封裝一個權(quán)責(zé)，只有一個修改的原因来屠，并于少數(shù)其他類一起協(xié)同達(dá)成期望的系統(tǒng)行為虑椎。
10.2.2 內(nèi)聚
類應(yīng)該有少量實(shí)體變量。類中的每個方法都應(yīng)該操作一個或多個變量俱笛。通常而言捆姜，方法操作的變量越多，就越黏聚在類上嫂粟。如果一個類中的每個變量被每個方法所使用娇未，則該類具有最大的內(nèi)聚性。
10.2.3 保持內(nèi)聚性會得到許多短小的類
當(dāng)類喪失了內(nèi)聚性星虹，就拆分它零抬。
10.3 為了修改而組織
對于大多數(shù)的系統(tǒng)，修改將一直持續(xù)宽涌。每處修改都讓我們冒著系統(tǒng)其他部分不能如預(yù)期般工作的風(fēng)險(xiǎn)平夜。在整潔的環(huán)境中，我們對類加以組織卸亮，以降低修改的風(fēng)險(xiǎn)忽妒。
隔離修改
需求會改變，所以代碼也會改變兼贸。我們學(xué)習(xí)到段直，具體類包含實(shí)現(xiàn)細(xì)節(jié)，而抽象類只呈現(xiàn)概念溶诞。依賴于具體實(shí)現(xiàn)的客戶類鸯檬，當(dāng)細(xì)節(jié)改變時，就會有風(fēng)險(xiǎn)螺垢。我們可以借助與接口和抽象類來隔離這些細(xì)節(jié)帶來的影響喧务。
第十一章 系統(tǒng)
11.1 如何建造一個城市
在較高的抽象層級---系統(tǒng)層級上保持代碼整潔。
11.2 將系統(tǒng)的構(gòu)造和使用分開
軟件系統(tǒng)在起始過程中和起始過程之后的運(yùn)行時邏輯分離開枉圃，在起始過程中構(gòu)建應(yīng)用對象功茴，也會存在相互纏結(jié)的依賴關(guān)系。
=====
