《敏捷式軟體開發 (Agile Software Development)》讀書筆記3

1、  如果一個類承擔的職責過多，就等於把這些職責耦合在了一起。一個職責的變化可能會削弱或者抑制這個類完成其他責任的能力。這種耦合會倒置脆弱的（fragile）設計，當變化發生時，設計會遭受到意想不到的破壞。P88

 

2、  在SRP中，我們把職責定義為“變化的原因”（a reson for change）。P89

 

3、  變化的軸線僅當變化實際發生時才具有真正的意義。如果沒有徵兆，那麼去應用SRP，或者任何其他原則都是不明智的。P90

 

4、  任何系統在其生命週期中都會發生變化。如果我們期望開發出的系統不會在第1版後就被拋棄，就必須牢牢地記住這一點。P92

 

5、  怎樣可能在不改動模組原始碼的情況下去更改它的行為呢？怎樣才能在無需對模組進行改動的情況下就改變它的功能呢？P93

答案：關鍵是抽象（或者介面）。

 

6、  既然不可能完全封閉，那麼就必須有策略地對待這個問題。也就是說，設計人員必須對於他設計的模組應該對那種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。P97

 

7、  這一點不容易做到。因為它意味著要根據經驗猜測那些應用程式生長曆程中有可能遭受的變化。如果開發人員猜測正確，他們就獲得成功。如果他們猜測錯誤，他們會遭受失敗。並且在大多數情況下，他們都會猜測錯誤。P98

 

8、  遵循OCP的代價也是昂貴的。建立正確的抽象是要花費開發時間和精力的。同時，那些抽象也增加了軟體設計的複雜性。開發人員有能力處理的抽象的數量也是有限的。顯然，我們希望把OCP的應用限定在可能會發生的變化上。P98

 

9、  我不希望設計背著許多不必要的抽象。通常，我們更願意一直等到確實需要那些抽象時再把它放置進去。P98

 

10、              為了防止軟體背著不必要的複雜性，我們會允許自己被愚弄一次。這意味著在我們最初編寫代碼時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離以後發生的同類變化。簡而言之，我們願意被第一顆子彈擊中，然後我們會確保自己不再被同一隻槍發射的其他任何子彈擊中。P98

 

11、              刺激變化——如果我們決定接受第一顆子彈，那麼子彈到來的越早、越快就對我越有利。我們希望在開發工作展開不久就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難。P98

 

12、              在許多方面，OCP都是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處（也就是，靈活性、可重用性以及可維護性）。然而，並不是說只要使用一種物件導向語言就是遵循了這個原則。對於應用程式中的每個部分都肆意地進行抽象同樣不是一個好主意。正確的做法是，開發人員應該僅僅對程式中呈現出頻繁變化的那些部分做出抽象。拒絕不成熟的抽象和抽象本身一樣重要。P101

 

13、              一個模型，如果孤立地看，並不具有真正意義上的有效性。模型的有效性只能通過它的客戶程式來表現。P107

 

14、              有誰知道設計的使用者會做出什麼樣的合理假設呢？大多數這樣的假設都很難預測。事實上，如果試圖去預測所有這些假設，我們所得到的系統很可能會充滿不必要的複雜性的臭味。因此，像所有其他原則一樣，通常最好的方法是只預測那些最明顯的對於LSP的違反情況而延遲所有其他的預測，直到出現相關的脆弱性的臭味時，才去處理它們。P107

 

15、              術語“IS-A”的含意過於寬泛以至於不能作為子類型的定義。子類型的正確定義是“可替換性的”，這裡的可替換性可以通過顯示或隱式的契約來定義。P115