前面兩部分分別講述了簡單工廠模式和策略模式，後面還舉了例子進行簡單實現，這裡，讓我們了解下軟體設計的初衷，整合書上分為3章書寫的內容，這裡我們統一介紹我們寫**應該注意的基本原則：
分別是a、單一職責原則：就乙個類而言，應該僅有乙個引起它變化的原因。
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者限制這個類完成其他職責的能力，當變化發生時，實際會遭到意想不到破壞；
當然，軟體實際真正要許多內容，就是發現職責並把哪些職責相互分離，其實要去判斷是否應該分離出類來，這也簡單，就是如果你能想到多餘乙個的動機去改變乙個類，那麼這個列就具有多於乙個的職責。
b、開放-封閉原則：軟體實體類（模組、函式等單獨個體）應該可以擴充套件，但是不可以修改
也就是說乙個類對於擴充套件是開放的，對於修改是封閉的。舉個簡單的例子就是說，如果乙個專案需要新增新的功能，不過這個新的功能與乙個老的功能相關，我們需要做的不是去修改老的類，增加乙個分支判斷，何時執行新功能，何時執行老功能，而是新建乙個類，繼承或實現老公能的類，從而實現新功能而不去修改老功能的類，這樣可以必變對原來的功能造成影響。
其實在這裡我們就可以重構專案了，因為無論模組是多麼的『封閉』，都會存在一些無法對已封閉的變化，既然不可能完全封閉看，世紀人員必須對於他設計的模組應該對那種變化封閉做出選擇，他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。當然，僅憑猜測肯定會有疏漏，我們希望在需求開始就知道後續的一系列變化，但我們也知道這是不可能的，所以，我們只能假設沒有變化，當需求到來的時候重構**架構，音節變化。
開放-封閉原則是物件導向設計的核心所在，遵循這個原則可以帶來物件導向技術所說的巨大好處，也就是可維護，可擴充套件，可復用，靈活性好，開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然而，對於應用程式中的每個部分都可以進行抽象同樣不是乙個好主意，拒絕不成熟的抽象和抽象本身一樣重要。
c、黎克特制代換原則：子型別必須能替換他的父型別
就是乙個原件實體如果能用乙個父類的話，那麼一定適用於其子類，而它察覺不出父類物件和子類物件的區別，也就是說，在軟體裡，吧父類都替換成其子類，程式的行為沒有變化。只有當子類可以替換掉父類，軟體單位的功能不受影響時，父類才能真正被復用，而子類需在父類的基礎上增加新的行為。
正式有圖子型別的可替換性，才使得使用父類型別的模組在無需修改的情況下實現拓展，實現開放封閉原則。
d、依賴倒轉原則：說白了就是針對介面變成，不要針對實現程式設計，即
1、高層模組不應該依賴低層模組，兩個都應該依賴抽象
2、抽象不應該依賴細節，細節應該依賴抽象
具體舉個例子，就是說不同專案之間，不同的人配合工作的時候，互相之間需要提供乙個api文件，寫明對方想調這個介面需要傳入什麼引數，可以獲得什麼結果，但是具體的方法內部是如何實現的，呼叫方不需要考慮，但是編寫api介面的人需要注意的是，雖然你內部如何實現別人不理會，但你內部的變化不能影響api介面的呼叫。
《大話設計模式》讀書筆記（四）
本文上接 大話設計模式 讀書筆記 三 本次主要介紹三種設計模式，外觀模式，建造者模式和觀察者模式。解決的問題 外觀模式，正像它的名字。對於一些實現十分複雜，但使用者又沒必要知道這些複雜細節的時候，外觀模式可以提供乙個統一的簡單介面。外觀模式主要用於將層與層之間分離，提供簡單介面等等功能。類圖結構 在...
大話設計模式讀書筆記之設計原則
1.單一職責原則 srp 對於乙個類而言，應該僅有乙個引起它變化的原因。如果你能夠想到多於乙個的動機去改變乙個類，那麼這個類就具有多於乙個的職責，就應該考慮類的職責分離。2.開放 封閉原則 是說軟體實體 對於類，模組，函式，方法等 對於擴充套件是開放的，對於修改是關閉。開放封閉原則是物件導向設計的核...
讀書筆記 大話設計模式
大話設計模式 的確寫的很不錯。把晦澀解懂的設計模式，講的通俗易懂。邊讀邊用evernote做筆記，把印象深刻的整理了一下。先補習一下uml的圖示法 繼承，介面，組合，依賴，關聯 策略模式 strategy 定義一系列演算法，所有演算法完成的都是相同的工作，只是實現不同。減少演算法與使用類之間的藕合。...