讀了《大話設計模式》，摘錄該書中講到的設計模式幾大原則，供日後使用。
一、單一職責原則
就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的 職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭 受到意想不到破壞。軟體真正要做的許多內容，就是發現職責並把那些職責相互分離。如果你能夠想到多於乙個的動機去改變乙個類，那麼這個類就具有多於乙個的 職責，就應該考慮類的職責分離。
二、開放-封閉原則
軟體實體（類、模組、函式等）應該可以擴充套件，但是不可以修改，即對於擴充套件是開放的，對於更改是封閉的。運 用開放-封閉原則可以使得軟體面對需求的改變卻可以保持相對穩定，從而使得軟體可以在第乙個版本以後不斷推出新的版本。換句話說，當面對需求，對程式的改 動是通過增加新的**進行的，而不是更改現有的**。無論模組多麼封閉，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的 模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離這些變化，等到變化發生時立即採取行動。於是，在我們最初編 寫**時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離以後發生的同類變化。
開放-封閉原則是物件導向設計的核心所在，遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然後，對於應用程式中的每個部分都刻意地進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
三、黎克特制代換原則
定義：子型別必須能夠替換掉它們的父型別。也就是說，乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它覺察不出父類物件和子類物件的區別，即在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。
四、依賴倒置原則
1、高層模組不應該依賴低層模組，兩個都應該依賴抽象。
2、抽象不應該依賴細節，細節應該依賴抽象。
換句話說，就是要針對介面程式設計，不要對實現程式設計。依賴倒置原則是物件導向設計的標誌，用哪種語言編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止於抽象類或者介面，那就是物件導向的設計，反之就是過程化的設計了。
正是有了黎克特制代換原則，才使得依賴倒置原則成為可能。由於子型別的可替換性才使得使用父類型別的模組在無需修改的情況下就可以擴充套件。
五、迪公尺特法則
又叫最少知識原則。如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過 第三者**這個呼叫。該法則首先強調的前提是在類的結構設計上，每乙個類都應該盡量降低成員的訪問許可權，即乙個類包裝好自己的private狀態，不需要 讓別的類知道的字段或行為就不要公開。
迪公尺特法則的根本思想，是強調了類之間的松耦合。
類之間的耦合越弱，越有利於復用，乙個處在弱耦合的類被修改，不會對有關係的類造成波及。
讀了《大話設計模式》，摘錄該書中講到的設計模式幾大原則，供日後使用。
一、單一職責原則
就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的 職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭 受到意想不到破壞。軟體真正要做的許多內容，就是發現職責並把那些職責相互分離。如果你能夠想到多於乙個的動機去改變乙個類，那麼這個類就具有多於乙個的 職責，就應該考慮類的職責分離。
二、開放-封閉原則
軟體實體（類、模組、函式等）應該可以擴充套件，但是不可以修改，即對於擴充套件是開放的，對於更改是封閉的。運 用開放-封閉原則可以使得軟體面對需求的改變卻可以保持相對穩定，從而使得軟體可以在第乙個版本以後不斷推出新的版本。換句話說，當面對需求，對程式的改 動是通過增加新的**進行的，而不是更改現有的**。無論模組多麼封閉，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的 模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離這些變化，等到變化發生時立即採取行動。於是，在我們最初編 寫**時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離以後發生的同類變化。
開放-封閉原則是物件導向設計的核心所在，遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然後，對於應用程式中的每個部分都刻意地進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
三、黎克特制代換原則
定義：子型別必須能夠替換掉它們的父型別。也就是說，乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它覺察不出父類物件和子類物件的區別，即在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。
四、依賴倒置原則
1、高層模組不應該依賴低層模組，兩個都應該依賴抽象。
2、抽象不應該依賴細節，細節應該依賴抽象。
換句話說，就是要針對介面程式設計，不要對實現程式設計。依賴倒置原則是物件導向設計的標誌，用哪種語言編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止於抽象類或者介面，那就是物件導向的設計，反之就是過程化的設計了。
正是有了黎克特制代換原則，才使得依賴倒置原則成為可能。由於子型別的可替換性才使得使用父類型別的模組在無需修改的情況下就可以擴充套件。
五、迪公尺特法則
又叫最少知識原則。如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過 第三者**這個呼叫。該法則首先強調的前提是在類的結構設計上，每乙個類都應該盡量降低成員的訪問許可權，即乙個類包裝好自己的private狀態，不需要 讓別的類知道的字段或行為就不要公開。
迪公尺特法則的根本思想，是強調了類之間的松耦合。
類之間的耦合越弱，越有利於復用，乙個處在弱耦合的類被修改，不會對有關係的類造成波及。
設計模式原則總結 讀《大話設計模式》有感
一 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到破壞。軟體真正要做的許多內容，就是發現職責並把那些職責相互分離。如...
《大話設計模式》設計原則
單一職責原則 srp 就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。軟體設計真正要做的許多內容，就是發現職責並把那些職責相...
讀《大話設計模式》 依賴倒轉原則
依賴倒轉原則 a.高層模組不應依賴低層模組，兩個都應該依賴抽象。b.抽象不應依賴細節，細節應該依賴抽象。說白了就是要針對介面程式設計，不要對是想程式設計。黎克特制代換原則 lsp 子型別必須能夠替換掉它們的父型別 說白了就是乙個軟體實體如果使用的是乙個父類的話，那麼它一定使用於子類，且它察覺不出父類...