白話設計模式六大原則

不管你是乙個android程式設計師還是ios，後台程式設計師，乙個好的程式設計師，不是只會埋頭敲**可以造就的，有時候抬頭思考腫麼把以後的**寫的更好更有價值。設計模式是一種思考腫麼構造**的方法。今天想結合例子談談設計模式的六大基本原則。希望能簡單點把問題說清楚，避免高大上的定義，虛無縹緲的遣詞造句。

一開始我需要乙隻會吃吃喝喝的寵物，於是我寫了

public class animal 
public void drink() 
}

乙個領養的方法

public class host 
}

然後我發現要區分下狗和貓的吃喝，我改

public class animal 
public void drink(string kind) 
}

單一職責原則：不要存在多於乙個導致類變更的原因

於是我新建了乙個類dog繼承了開始的時候的animal，至於為什麼要繼承。。。**於直覺。。。animal>dog。。。包含關係不是嗎？

public class dog extends animal
public void drink() 
}

寫完了以後發現有點不對勁，貌似違反了

黎克特制替換原則：子類可以擴充套件父類的功能，但不能改變父類原有的功能。

我這樣一寫如果把用到animal的地方換成dog，所有的動物都變成吃骨頭了。

既然繼承不能用了，領養的方法出現了難題，我總不能

public void adopt(dog dog)
public void adopt(cat cat)

.....無數雞，鴨，鵝方法飛過......

要是真這樣估計累死。於是，我想到了介面

public inte***ce animal 
public class dog implements animal
public void drink() 
}

完美。契合了面向介面程式設計，而且符合

依賴倒置原則：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象

領養方法做為高層模組沒有直接依賴貓貓狗狗等低層模組，依賴了其抽象，擴充套件性棒棒的。

然後發現貓有爬樹的技能，狗有汪汪的神級，於是我加了

public inte***ce animal

於是狗變成

public class dog implements animal
public void drink() 
@override
public void climbtree() 
@override
public void yell() 
}

由於狗不會爬樹，所以爬樹的方法空著。轉而一想這樣不行，狗還不會飛，不會。。。。等引入其他大量動物，豈不是有大量的空方法？

介面隔離原則：客戶端不應該被強迫地依賴那些根本用不上的方法。

我只好把介面拆開，用組合搞定，組合是比較推薦的方式。

public inte***ce animal 
public inte***ce yell 
public class dog implements animal, yell
public void drink() 
@override
public void yell() 
}

這樣狗還有其他技能也可以實現其他介面，當然其他動物要是有相同的技能可以實現相同的介面。關鍵是沒有空方法了，哈哈。

防疫站需要每個寵物的資訊，這時候需要乙個epidemicstation物件。如何獲取寵物資訊有2種方式

我們肯定直接會選擇第一種。。。直覺是可以少建個物件。。。早說了我就是這種偷懶的程式猿。。。然而莫名的契合了迪公尺特法則

迪公尺特法則:乙個物件應該對其他物件保持最少的了解

host只需要對animal物件保持關注，而epidemicstation只需要對host物件保持關注。epidemicstation物件不需要了解animal。感覺直接點就是，在乙個類中應該少出現其他類，其實這也是解耦的需要。

直接丟擲定義吧

開閉原則：乙個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉

感覺這個原則容易看懂，最難做到。白話就是不要改你以前寫的**，你應該加一些**去擴充套件原來的功能，來實現新的需求。好處很好理解，改原來的**很容易影響原來的功能，特別是接手別人的**，不理解原先業務場景的情況下。關於『不要動之前的**』感覺槽點無數啊，看自己寫的**想吐有木有？別人的**簡直...?之前**會想到會有這種鬼需求？.......

設計模式六大原則

0.05 設計模式設計模式規範筆記大話設計模式物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件封閉更改的效果。1 單一職責原則就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...

設計模式六大原則

參考文章單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為就乙個類而言，應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放，對修改關閉。...

白話設計模式六大原則

設計模式六大原則

設計模式六大原則

設計模式六大原則

相關推薦