敏捷軟件開發：原則、模式與實踐-讀書筆記1

1. 單一職責鏈原則（SRP）：
   1. 爲何要把兩個職責分類到單獨的類中：因爲每一個職責都是變化的軸線，當需求變化時，改變化會反應爲類的職責的變化，如果一個類承擔了多於一個的職責，那麼引起他變化的原因就會有多個；維度越多，責任越大，越不好控制
   2. 如果一個類承擔的職責過多，就等於把這些職責耦合在一起了。一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱設計，當發生變化時，設計會遭受到意想不到的破壞。責任在一個類中的耦合會導致，類中存在錯綜交雜的關係線，一旦某個節點的變動可能會引起額外的未測試到的問題。
   3. 如果能夠想到多於1個的動機去改變一個類，那麼這個類就具有多於一個職責，我們習慣於以組的形式去考慮職責。職責組是否應該分開，這 依賴於應用程序的變化方式，如果應用程序的變化方式會影響連接函數的簽名，那麼這個 設計就具有僵化性的臭味，因爲調用的類必須重新編譯，部署的次數常常會超過我們希望的次數，在這種情況下，就應該分離多個職責。一個職責的變化引起其他類的變動，建議拆分職責組。另一方面，如果應用程序的變化總是導致這兩個職責同時變化，那麼就不應該分離他們。
   4. 常見的違反單一職責的情形。某類同時包含了業務規則和持久化的控制。這兩個職責在大多數情況下 決不 應該混合在一起的，業務規則往往會頻繁的變化，而持久化的變化確不會如此頻繁的變化，並且變化的原因也是完全不相同的，把業務和持久化子系統綁定在一起的做法是不合理的。
   5. 建議使用Facede或則proxy模式對設計進行重構，分離職責。
2. 開發-封閉原則（OCP）
   1. 軟件實體（類，模塊，函數等等）應該是可以擴展的，但是不可修改的。
   2. 如果程序中一處改動就會產生連鎖反應，導致一系列相關模塊的改動，那麼設計就具有僵化性的臭味。如果正確的應用OCP，那麼以後的改動在進行相同的改動時，就只需要添加新的代碼，而不必改動已經運行正常的代碼。
   3. 對擴展是開放的，這意味着模塊的行爲是可擴展的，當應用的需求改變時，我們可以對模塊進行擴展，使其具有滿足那些改變的新行爲，換句話說，我們可改變模塊的功能。對更改時封閉的，多模塊行爲進行擴展時，不必改動模塊的源代碼或者二進制代碼，模塊的二進制可執行版本無論是可連接的庫，dll或者java的jar文件，都無需改動。已經生的二進制文件都無需改動。
   4. 如何去隔離變化呢，我們會在可能變化的地方放置吊鉤（hock），然而我們放置吊鉤常常是錯誤的。通常，我們更原因一直等到確實需要那些抽象的對象時再把它放置進去。
3. Liskov替換原則（LSP）
   1. 子類型必須能夠替換掉他們的基類型；
   2. 我們經常說繼承是IS-A的關係，也就是說，如果一個新類型的對象被對象認知爲和一個已有類的對象滿足IS-A關係，那麼這個新的對象類應該從這個已有對象派生。
   3. 如果一組類都支持一個公共的職責，那麼他們應該從 一個公共的超類繼承該職責，如果公共的超類還不存在，那麼創建一個，並把公共的職責放入其中。畢竟，這樣的一個類的有用性是確定無疑的-你已經提示了一些類會繼承這些 職責，然而稍後對系統的擴展也許會加入一個新的子類，該子類很可能會以新的方式來支持同樣的職責，此時，創建的超類可能是一個抽象類。提取公共的職責作爲超類的原則。
4. 依賴倒置原則（DIP）
   1. 高層模塊不應該依賴於低層模塊，二者都應該依賴於抽象
   2. 抽象不應該依賴於細節，細節應該依賴於抽象。
   3. 較爲合適的模型，每個較高層次都爲它所需要的服務申明一個抽象接口，較低的層次實現了這些抽象接口，每個高層類都通過該抽象接口使用下一層的，這樣高層就不依賴於低層。低層反而依賴於在高層中聲明的抽象服務接口。請注意這裏的倒置不僅僅是依賴關係的倒置，他也是接口所有權的倒置。
   4. 低層模塊實現了在高層模塊中聲明並被高層模塊的調用的接口。
   5. DIP的解釋，依賴於 抽象，該啓發規則建議不應該依賴於具體的類，也就是說，程序中所有的依賴關係都應該終止於抽象類或者接口。推出以下 ：任何變量都不應該持有一個指向具體類的指針或者引用；任何類都不應該從具體類派生；任何方法都不應該覆它的任何基類中已經實現了的方法。
   6. 什麼是高層策略，它是應用背後的抽象，是哪些不隨具體細節的改變而改變的真理。他是系統內部的系統-它是隱喻。
5. 接口隔離原則（ISP）
   1. 不應該強迫客戶依賴於它們不用的方法。
   2. 這個原則用來處理胖接口所具有的缺點，如果類的接口不是內聚的，就表示該類具有胖的接口。換句話說，類的胖接口可以分解成多組方法，每一組方法都服務於一組不同的客戶程序。可做到函數間的拆分，以便以後更好地組合。