不管做什麼事情都要有原則，都要有標準，學習設計模式也是一樣，設計模式的原則蘊含在很多設計模式中，它們是從許多設計方案中總結出的指導性原則。物件導向設計原則支援可維護性復用而誕生，來了解一下具體的設計模式原則都是什麼。
1、是什麼：
就乙個類而言，應該僅有乙個引起它變化的原因。
2、怎麼來的：
如果乙個類承擔的職責過多，就等於這個類太「累」，就等於把這些職責耦合在一起，乙個職責的變化可能或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
3、怎麼用：
乙個類只負責一項職責，如果乙個類包含多種職責，就把這些職責相互分類。通俗的說就是，如果你能夠想到多於乙個的動機去改變乙個類，那麼這個類就具有多餘乙個的職責，就應該考慮類的職責分離。
4、為什麼要用：
☞可以降低類的複雜度，乙個類只負責一項責，其邏輯肯定要比負責多項職責簡單多；
☞提高類的可讀性，提高系統的可維護性；
☞變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改乙個功能時，可以顯著降低對其他功能的影響
☞實現高內聚、低耦合的指導方針，做到了易維護、易擴充套件、易復用、靈活多樣。
1、是什麼：
軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可修改。對於擴充套件是開放的，對於修改是封閉的。
2、怎麼來的：
我們在做系統的時候，都不要指望系統一開始是需求確定，就再也不會變化，這是不現實也不科學的想法，而既然需求使一定會變化的，那麼如何在面對需求的變化時，設計的軟體可以相對容易修改，不至於說，新需求一來，就要把整個程式推到重來。怎樣的設計才能面對需求的改變卻可以保持相對穩定，從而使得系統可以在第乙個版本以後不斷的推出新的版本呢？這時開放-封閉原則就來了。
3、怎麼用：
設計軟體要容易維護又不容易出問題的最好的辦法，就是多擴充套件，少修改。為了滿足此原則，需要對系統進行抽象化設計，抽象化是開閉原則的關鍵。無論模組是多麼的『封閉』，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。在我們最初編寫**時，假設變化不會發生，當變化發生時，就立即採取行動，我們就建立抽象來隔離以後發生的同類變化。面對需求，對程式的改動是通過增加新**進行的，而不是更改現有的**，這就是「開放-封閉原則」的精神所在。
4、為什麼要用：
開放封閉原則是物件導向設計的核心所在。是物件導向設計的目標。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然而，對於應用程式中的每乙個部分都刻意的進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
1、是什麼：
抽象不應該依賴於細節, 細節依賴於抽象。針對介面程式設計，不要對實現程式設計。高層模組不應該依賴底層模組。兩個都應該依賴抽象。
2、怎麼來的：
在面向過程開發時，為了使得常用**可以復用，常常把這些**寫入函式的程式庫，在做新的專案的時候，去呼叫這些低層的函式就可以了。我們做的專案大多要訪問資料庫，所以我們就把訪問資料庫的**寫成了函式，侮次做新專案時就去呼叫這些函式。這也就叫做高層模組依核低層模組。」我們要做新專案時，發現業務邏輯的高層模組都是一樣的，但客戶卻希望使用不同的資料庫或儲存資訊方式，這時就出現麻煩了。我們希望能再次利用這些高層模組，但高層模組都是與低層的訪問資料庫繫結在一起的，沒辦法復用這些高層模組，這就非常糟糕了。而如果不管高層模組還是低層模組，它們都依賴十抽象，具體一點就是介面或抽象類，只要介面是穩定的．那麼任何乙個的更改都不用擔心其他受到彬響，這就使得無論高層模組還是低層模組都可以很容易地被復用。這才是最好的辦法。」
3、怎麼用：
類a的方法依賴類b，如果需要a通過c來實現同樣的功能，則必須通過修改類a的**來達成。這種場景下，類a一般是高層模組，負責複雜的業務邏輯；類b和類c是低層模組，負責基本的原子操作；假如修改類a，會給程式帶來不必要的風險。將類a修改為依賴介面i，類b和類c各自實現介面i，類a通過介面i間接與類b或者類c發生聯絡，則會大大降低修改類a的機率。
☞每個類盡量都有介面或抽象類，或者抽象類和介面兩者都具備。
☞變數的顯示型別盡量是介面或者是抽象類。
☞任何類都不應該從具體類派生。
☞盡量不要覆寫基類的方法。
☞結合黎克特制替換原則使用。
4、為什麼要用：
採用依賴倒置原則可以減少類間的耦合性，提高系統的穩定性，減少並行開發引起的風險，提高**的可讀性和可維護性。
依賴倒置原則的優點在小型專案中很難體現出來，例如小於10個人月的專案，使用簡單的ssh架構，基本上不費太大力氣就可以完成，是否採用依賴倒置原則影響不大。但是，在乙個大中型專案中，採用依賴倒置原則可以帶來非常多的優點，特別是規避一些非技術因素引起的問題。專案越大，需求變化的概率也越大，通過採用依賴倒置原則設計的介面或抽象類對實現類進行約束，可以減少需求變化引起的工作量劇增的情況。人員的變動在大中型專案中也是時常存在的，如果設計優良、**結構清晰，人員變化對專案的影響基本為零。大中型專案的維護週期一般都很長，採用依賴倒置原則可以讓維護人員輕鬆地擴充套件和維護。
1、是什麼：
子型別必須能夠替換掉他們的父型別。（乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件的區別。在軟體裡面，把父類都替換成它的子類，程式的行為沒有變換。）
2、怎麼來的：
在依賴倒轉原則中，不管是高層模組還是底層模組，他們都依賴於抽象，具體就是介面和抽象類，只要介面是穩定的，那麼任何乙個的更改都不用擔心其他受到影響。為什麼依賴了抽象的介面或抽象類，就不怕更改呢？這時就出現了黎克特制代換原則。
3、怎麼用：
黎克特制替換原則通俗的來講就是：子類可以擴充套件父類的功能，但不能改變父類原有的功能。它包含以下4層含義：
☞子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
☞子類中可以增加自己特有的方法。
☞當子類的方法過載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬鬆。
☞當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
4、為什麼要用：
黎克特制代換原則是實現開閉原則的重要方式之一，由於使用父類物件的地方都可以使用子類物件，因此在程式中盡量使用父類型別來對物件進行定義，而在執行時再確定其子類型別，用子類物件來替換父類物件。
summary：
在大多數情況下，這開放-封閉原則、依賴倒轉原則、黎克特制代換設計原則會同時出現，開閉原則是目標，黎克特制代換原則是基礎，依賴倒轉原則是手段，它們相輔相成，相互補充，目標一致，只是分析問題時所站角度不同而已。
1、是什麼：
如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫。乙個物件應該對其他物件保持最少的了解。
2、怎麼來的：
類與類之間的關係越密切，耦合度越大，當乙個類發生改變時，對另乙個類的影響也越大。因此盡量降低類與類之間的耦合
3、怎麼用：
（1）每乙個類都應當盡量降低成員的訪問許可權
（2）迪公尺特法則其根本思想是強調了類之間的松耦合。類之間的耦合越弱，越有利於復用，乙個處在弱耦合的類被修改，不會對有關係的類造成波及。體現了封裝的思想。
（3）在類的設計上，只要有可能，乙個類應當設計成不變的類。
（4）在對其他類的應用上，乙個物件對其他類的物件的應用應該降到最低。
（5）盡量限制區域性變數的有效範圍。
4、為什麼要用：
迪公尺特法則是一種物件導向系統設計風格的一種法則，尤其適合做大型複雜系統設計指導原則。但是也會造成系統的不同模組之間的通訊效率降低，使系統的不同模組之間不容易協調等缺點。同時，因為迪公尺特法則要求類與類之間盡量不直接通訊，如果類之間需要通訊就通過第三方**的方式，這就直接導致了系統中存在大量的中介類，這些類存在的唯一原因是為了傳遞類與類之間的相互呼叫關係，這就毫無疑問的增加了系統的複雜度。解決這個問題的方式是：使用依賴倒轉原則（通俗的講就是要針對介面程式設計，不要針對具體程式設計），這要就可以是呼叫方和被呼叫方之間有了乙個抽象層，被呼叫方在遵循抽象層的前提下就可以自由的變化，此時抽象層成了呼叫方的朋友。
1、是什麼：
盡量使用合成、聚合，盡量不要使用類繼承。
2、怎麼來的：
很多情況下，使用繼承會帶來很多麻煩。物件的繼承關係是在編譯時就定義好了，所以無法在執行時改變從父類繼承的實現。子類的實現與它的父類有非常緊密的依賴關係，以至於父類實現中的任何變化必然會導致子類發生變化。當你需要復用子類時，如果繼承下來的實現不適合解決新的問題，則父類必須重寫或被其他更適合的類替換。這種依賴關係限制了靈活性並最終限制了復用性，所以就優先使用物件合成、聚合，而不是類繼承。這就是合成、聚合復用原則的具體體現。
3、怎麼用：
如果兩個類之間是「has-a」的關係應使用組合或聚合，如果是「is-a」關係可使用繼承。"is-a"是嚴格的分類學意義上的定義，意思是乙個類是另乙個類的"一種"；而"has-a"則不同，它表示某乙個角色具有某一項責任
4、為什麼要用：
優先使用物件的合成聚合將有助於你保持每個類被封裝，並被集中在單個任務上。這樣類和類繼承層次會保持較小規模，井且不太可能增長為不可控制的龐然大物。
設計模式的原則雖然不多，但是卻深刻的理解到了設計模式的精彩，要認真的去探索每乙個原則的精髓，並且要把這些原則運用到我們實際的程式中，讓**更加的簡練，更加容易維護，容易擴充套件和復用。
C 設計模式之 設計原則
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。對於擴充套件是開放的，對於更改是封閉的 依賴倒置原則 抽象不應該依賴細節，細節應該依賴於抽象，也就是說要針對介面程式設計，...
設計模式 設計模式原則
1 單一職責原則 srp 乙個類應當只有乙個引起其變化的原因。使用單一職責原則的好處有 1 類的複雜性降低 2 可讀性提高 3 可維護性提高 4 變更引起的風險降低 2 黎克特制替換原則 lsp 在使用父類的地方，可以使用其子類替換。黎克特制替換原則的含義 1 子類必須完全實現父類的方法 2 子類可...
設計模式 設計原則
1.單一職責原則 single responsibility principle，簡稱srp 就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到...