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
敏捷軟體開發讀書筆記 敏捷軟體開發宣言及其原則
原文 the agile alliance its principles 根據個人理解翻譯，僅供參考 敏捷軟體開發宣言 個體與交流 勝過過程和工具 可用的軟體 勝過面面俱到 的文件客戶協作 勝過合同談判 響應變化 勝過遵循計畫 上列各條中，右側雖然也有價值，但左側的價值更大。敏捷宣言原則 1.盡早並...
敏捷軟體開發讀書筆記 敏捷軟體開發宣言及其原則
原文 the agile alliance its principles 根據個人理解翻譯，僅供參考 敏捷軟體開發宣言 個體與交流 勝過過程和工具 可用的軟體 勝過面面俱到 的文件 客戶協作 勝過合同談判 響應變化 勝過遵循計畫 上列各條中，右側雖然也有價值，但左側的價值更大。敏捷宣言原則 1.盡早...
物件導向設計原則 《敏捷軟體開發》讀書筆記
摘抄自 敏捷軟體開發 原則 方法與實踐 robert c.martin 1 srp 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。職責即為 變化的原因 2 ocp 開放封閉原則 軟體實體 類 模組 函式等 應該是可以擴充套件的，但是不可修改。對於擴充套件是開放的,對於更改是封閉的.關鍵是...