看到第5張重構的時候，最終版的代碼寫的是真好。
優點：代碼具有高可讀性，基本就是讓代碼說話了，可以節省後面人閱讀改代碼的時間
缺點：但是我感覺是不是有點過度重構了，三行代碼也要重新寫個方法？本來開發時間有限，而且程序員設計好的類名和方法名的時候感覺是挺費時的一件事。我們是要開始寫代碼的時候就嚴格按照這種規範，還是可以先實現功能，然後後面進行重構呢，如果時間緊急又該如何？
在萌芽培訓中我找到了答案：
1.不承認上線時間。先估算實現功能，最優設計等分別需要多長時間，如果pd數不夠，可和leader和PM商量。
2.在緊急編碼時，時間優於編碼規範，可在下一個版本上線的時候把優化的代碼帶上去。
看到第6章的時候，感覺這本書說的有的也不太對，但又說不上錯。
在開發的時候，是覺得可能會出現的那種情況而預先設計好呢，還是等到真正遇到那種情況纔去改善（書中似乎認同後者，但我覺得前者也挺好啊）。
解答：看完第7章後，原來是這樣的：我們不需要在一開始設計這個模塊時就試圖預測程序將如何變化。而是先已最簡單的方法去編寫，直到需求最終確實變化時，才修改模塊設計，使之對該這種變化保持彈性。
記得在學校的時候，老師總是和我們說，做項目得擁抱需求、擁抱變化，讓自己做出來的項目不懼怕需求的變更。那時的我在想，要擁抱變化就是要預先考慮到需求可能會有哪些變化，提前做好相應的設計。
但是在讀了這本書之後，發現不是這樣的了。
收穫：
1.保持儘可能好的設計
敏捷開發人員不是每幾周才清潔自己的設計，而是每天、每小時、每分鐘都保持軟件儘可能的乾淨、簡單並且富有表現力。絕不會說“稍後我會回來修復它”，絕不讓代碼的腐化出現。
2.不預先做過多的設計
敏捷開發人員不會對一個龐大的需求預先設計應用哪些原則和設計模式。相反，那些原則和模式被應用在一次次的迭代中，力圖使代碼以及代碼所表達的設計保持乾淨。
Principle
單一職責原則（SRP）：
就一個類而言，應該僅有一個引起它變化的原因。
問題：T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。也就是說職責P1和P2被耦合在了一起。
解決：遵守單一職責原則，將不同的職責封裝到不同的類或模塊中。
感想：
如果一個類承擔的職責過多，就等於把這些職責耦合在一起，會影響複用性。軟件設計真正要做的許多內容，就是發現職責並把那些職責互相分離。
開放封閉原則（OCP）：
軟件實體（類，模塊，函數等等）應該是可以擴展的，但是不可修改的。
描述：“對擴展開放，對更改封閉”。
對擴展開放，意味着有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況。
對修改封閉，意味着類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改。
感想：
要實現開放封閉原則，最重要的就是對頻繁變化的部分進行抽象，但是不要對程序中的每個部分肆意地進行抽象。
Liskov替換原則（LSP）：
子類型必須能夠替換掉它們的基類型
重要內容記錄：對象的行爲方式纔是軟件真正所關注的問題，LSP清晰的指出，OOD中IS-A關係是就行爲方式而言的，行爲方式是可以進行假設的，是客戶程序所依賴的。那如何合理假設行爲方式呢？
答：使用基於契約設計（Design By Contract，DBC），契約是通過爲每個方法聲明前置條件和後置條件來指定的。要使一個方法得以執行，前置條件必須爲真。執行完畢後，該方法要保證後置條件爲真。
派生類的前置條件和後置條件規則：
在重新聲明派生類的例程中，只能使用相等或者更弱的前置條件來替換原始的前置條件，只能使用相等的或者更弱的後置條件來替換原始的後置條件。（聯想到了Java中，派生類子類的重載方法訪問優先級應該不低於基類，這也是遵循後置條件規則吧）。
特別的：當派生類的方法中添加了基類不會拋出的異常，如果基類的使用者不期望這些異常，那麼把他們添加到派生類的方法中就會導致不可替換性。此時要遵循LSP，要麼必須改變使用者的期望，要麼派生類就不該拋出這些異常。
結論：LSP是使OCP成爲可能的主要原則之一。正是子類型的可替換性才使得使用基類型的模塊在無需修改下就可以擴展。這種可替換性必須是可以隱式依賴的東西。因此，如果沒有顯示地強制基類類型的契約，那麼代碼就必須良好的並且明顯地表達出這一點。術語“IS-A”的含義過於寬泛以至於不能作爲子類型的定義。子類型的正確定義是“可替換性的”，這裏的可替換性可以通過顯示或者隱式的契約來定義。
自己理解：設計的時候一定要從行爲上判斷兩個類之間是否具有is-a關係，如果不存在，將兩個類的具有公共行爲的方法提取到接口中，功能相似但是行爲不同的，獨自放入各自方法中，使得設計符合LSP。（P111）
問：是否子類重寫了父類方法，那麼通常就違法了LSP了？ 非也
依賴倒置原則（DIP）：
高層模塊不應該依賴於底層模塊，兩者都應該依賴於抽象。
抽象不應該依賴於細節，細節應該依賴於抽象。
依賴倒置原則的本質就是通過抽象(接口或抽象類)使各個類或模塊的實現彼此獨立，不互相影響，實現模塊間的鬆耦合。我們在項目中使用這個原則要遵循下面的規則：
每個類儘量都有接口或者抽象類，或者抽象類和接口兩都具備
變量的表面類型儘量是接口或者抽象類
任何類都不應該從具體類派生
儘量不要覆寫基類的方法
如果基類是一個抽象類，而這個方法已經實現了，子類儘量不要覆寫。類間依賴的是抽象，覆寫了抽象方法，對依賴的穩定性會有一定的影響。
結合里氏替換原則使用
里氏替換原則：父類出現的地方子類就能出現。結合本章我們得出了一個通俗的規則：接口負責定義public屬性和方法，並且聲明與其他對象的依賴關係。抽象類負責公共構造部分的實現，實現類準確的實現業務邏輯，同時在適當的時候對父類進行細化。
依賴倒置原則是6個設計原則中最難以實現的原則，它是實現開閉原則的重要方法，在項目中，大家只要記住是”面向接口編程”就基本上是抓住了依賴倒置原則的核心了。
接口隔離原則（ISP）：
不應該強迫客戶端依賴於它們不用的方法。
自己理解：接口隔離主要是不要讓一個接口在含有許多方法的同時，被其他實體類依賴，被實體類依賴的接口不應該包含該實體類不需要的方法。