畢竟是做了兩年的開發，對於設計模式的六大原則算是有點熟悉的，只是沒了解的這麼全面，這次咱們一次講清楚這六大原則是啥。
對擴充套件開放，對修改關閉。（在不改變原有**的基礎上通過擴充套件來實現新功能）
這條設計原則是六條裡最重要的！
軟體的相容性其實是很重要的東西，咱們不能輕易的把原先程式的功能做修改，這樣子相容性就很差了。想實現或者修改乙個功能時，最好能通過新增模組的方式實現。
舉個例子，做乙個遊樂場的售票功能。某天遊樂場舉辦活動，在滿足某些條件時顧客可以享受折扣優惠。
比較差勁的做法是，直接把計算票價的函式給改掉。
比較好的做法是，先做一層封裝，比如搞個抽象類，這類裡存放的是方法，然後用抽象類的不同子類去不同的實現計算票價的方法。如此一來，舊的計算票價的方法還在那裡，只是通過擴充套件了新的方法，滿足了需求。某天活動結束了，舊的功能還能繼續用。
這個原則之前鵬哥講過，當時我還認真聽了一下。即，子類必須能替換他們的父類！比如我寫個函式，形參是父類物件，那麼它就一定必須能接受乙個子類物件，而且程式不會產生任何錯誤或者是異常。
這個原則其實是為了約束大家，不要瞎搞類的繼承，要按照這個規則來搞繼承。
我們聊幾個可能違背裡式替換原則的做法：
1.子類丟擲了父類不可能會丟擲的異常。
這就純屬坑爹了，如何處理呢？很簡單，請子類自我消化掉這些異常。
2.退化函式。
退化函式就是，子類override了父類的乙個函式，但是它啥也不做。
那咱們應該怎麼做來避免違反裡式替換原則呢？
我個人認為，子類盡量不要去override父類的非抽象方法，因為一旦你override了父類的非抽象方法，那就有點僵硬了，比如上面我說的異常，當然還有很多。如果你非要override父類方法，那就請你把父類的方法寫成抽象方法，這就萬事大吉了。如果你非得override父類的普通方法，那請把輸入範圍搞得更大，但是輸出搞得更嚴格。（寬進嚴出）
這個我之前不是很熟悉，咱們一起了解一下。
抽象不應該依賴於具體類，具體類應當依賴於抽象。
這句話其實非常好理解，講的就是，要針對介面程式設計，而不是針對實現程式設計。
啥意思呢？其實很簡單，比如函式在接受輸入引數的時候，盡量不要接受一種實現類物件，而是多接受一點抽象類物件，你懂我意思吧？
另外呢，想實現這個原則，咱們就得在某些地方上約束一下自己了。比如說，子類就盡量不要搞一些抽象類沒有的東西，不然咱們呼叫的時候還是得接受乙個實現類的物件，這就很僵硬。
乙個類只負責乙個功能領域中的相應職責。
換句話說，如果這個類需要改變，那麼原因只能是乙個。
兄弟，想想，如果乙個類的功能太多，那麼這些功能和功能之間的耦合就很緊密，這很僵硬的。而且，這個類的職責越多，這段**被復用的可能性就降低了。（啥？你說你喜歡寫**？）
為了滿足這條規則，咱們得做好職責劃分，這個具體情況具體分析。
使用多個專門的介面，而不使用單一的總介面，即客戶端不應該依賴那些它不需要的介面。
其實就是用單一職責的思想去規範介面設計。別把所有的介面放在一起，咱們按照功能將介面做分割。
總之，對於介面，該幹的事情都得幹，不該幹的事情別幹。
也叫迪公尺特原則。
通俗的來講，就是乙個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類來說，無論邏輯多麼複雜，都盡量地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外洩漏任何資訊。迪公尺特法則還有乙個更簡單的定義：只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每個物件都會與其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變數、方法引數、方法返回值中的類為直接的朋友，而出現在區域性變數中的類則不是直接的朋友。也就是說，陌生的類最好不要作為區域性變數的形式出現在類的內部。
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
參考文章 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放，對修改關閉。...