設計模式中的六大原則，保證了程式的可維護性、可擴充套件性、可復用性和靈活性。
六大原則是我們寫程式過程中重要的原則，只***了這些原則，程式才能達到物件導向的根本目的。
定義：就乙個類而言，應該僅有乙個引起它變化的原因。
解釋：簡單的理解，功能要單一。如果乙個類承擔的指責過多，就相當於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計可能會遭遇意想不到的破壞。如《大話設計模式》中的的例子，雖然手機功能眾多，（就目前而言）拍照是比不上單反的，音質也比不上專業的***，所以大多情況下，一件產品功能單一，職責單一，或許是更好的選擇。
舉個栗子：在程式中應該如何做呢，《大話設計模式》有乙個介紹遊戲的例子，把程式分為兩個類，乙個是遊戲的邏輯類，乙個是遊戲的窗體類。若要改變遊戲的介面，只需修改窗體類就好了，和邏輯類沒有關係，這樣在大型遊戲或其他程式修改的時候會減少不少的**量，以達到復用的目的。
總結：在編寫**前，要在類的職責分離上多加思考，做到單一職責，這樣我們的**才是真正的具有維護性、復用性和靈活性。
定義：軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可修改。
解釋：開放封閉原則是物件導向的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件。可復用、靈活性好。面對需求，對程式的改動是通過增新的類實現的，而不是更改現有的**。開放指的主要為功能擴充套件，封閉則是對於原有功能的**不可更改性。
總結：開放封閉原則是物件導向的核心，在程式增加新需求時一定要記得此原則。
定義：a、高層模組不應該依賴地層模組。兩個都應該依賴抽象。b、抽象不應該依賴細節。細節應該依賴抽象。
解釋：把pc電腦理解成大的軟體系統，任何部件如cpu、記憶體、硬碟顯示卡等都可以理解成程式中封裝的類或程式集，由於pc機易插拔的方式，不管哪乙個部件出了問題，都可以在不影響其他部件的情況下進行修改或更換。
總結：pc機中的易插拔，很好的解釋了程式中強內聚、松耦合的優點。
定義：子型別必須能夠替換他們的父型別。
解釋：就是乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且還察覺不出父類和子類物件的區別。也就是說在程式中，把父類都替換成它的子類，程式的行為沒有變化。只有當子類可以替換掉父類，軟體單位的功能不受影響時，父類才真正被復用，而子類也能夠在父類的基礎上增加新的行為。
舉個栗子：貓繼承了動物類，以動物的身份擁有吃、喝、跑、叫等行為，若需要增加狗、羊、馬類似的功能，由於他們都是繼承與動物類，所以只更改例項化的地方即可。
總結：用什麼語言寫的程式不重要，如果編寫的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止於抽象類或者介面，那就是物件導向的設計，反之那就是過程化的設計了。
定義：如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。
解釋：迪公尺特法則首先強調的前提是在類的結構設計上，每乙個類都應當盡量減低成員的訪問許可權，也就是，乙個類包裝好自己的private狀態，不需要讓別的類知道的字段就不要公開。迪公尺特法則其根本思想，是強調類之間的松耦合。例如書中的例子，小菜只需要認識it部門的主管就可以了，由他來安排工作，即是小張沒有時間，那麼還可以讓小李來做哦。同樣道理，我們在程式設計時，類之間的耦合越弱，越有利於復用，乙個處於弱耦合的類被修改，不會對有關係的類造成波及，也就是，資訊的隱藏促進了軟體的復用。
舉個栗子：沒有熟人其實也能夠辦成事的，只要it部的主管，將工作分配好了，那麼就會有人幫助小菜了。
總結：迪公尺特法則強調的是在類與類之間沒有直接的關係，相互通訊、呼叫只能借助第三方，強調了類之間的松耦合。
定義：盡量使用物件組合，而不是繼承來達到復用的目的。
解釋：聚合表示一種弱的「擁有」關係，提現的是a物件可以包含b物件，但b物件不是a物件的一部分；合成則是一種強的「擁有」關係，提現了嚴格的部分和整體的關係，部分和整體的生命週期一樣。
舉個栗子：雁群和大雁是聚合關係，而大雁和翅膀是合成關係。
六大原則是編寫程式必須遵守的重要原則，只有這樣，才能夠寫出可維護、可擴充套件、可復用和靈活性好的程式。
這些原則是物件導向程式設計的基礎，所以要好好練習充分理解並掌握六大原則
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
參考文章 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放，對修改關閉。...