一開始我需要乙隻會吃吃喝喝的寵物，於是我寫了
public
class
animal
public
void
drink
()}
public
class
host
}
public
class
animal
public
void
drink
(string kind)
}
單一職責原則：不要存在多於乙個導致類變更的原因於是我新建了乙個類dog繼承了開始的時候的animal，至於為什麼要繼承。。。**於直覺。。。animal>dog。。。包含關係不是嗎？
public
class
dogextends
animal
public
void
drink
()}
黎克特制替換原則：子類可以擴充套件父類的功能，但不能改變父類原有的功能。我這樣一寫如果把用到animal的地方換成dog，所有的動物都變成吃骨頭了。
既然繼承不能用了，領養的方法出現了難題，我總不能
public
void
adopt
(dog dog)
public
void
adopt
(cat cat)
.....無數雞，鴨，鵝方法飛過......
public
inte***ce
animal
public
class
dogimplements
animal
public
void
drink
()}
具體內容：面向介面程式設計，依賴於抽象而不依賴於具體。寫**時用到具體類時，不與具體類互動，而與具體類的上層接**互。
然後發現貓有爬樹的技能，狗有汪汪的神級，於是我加了
public
inte***ce
animal
public
class
dogimplements
animal
public
void
drink
() @override
public
void
climbtree
() @override
public
void
yell
()}
介面隔離原則：客戶端不應該被強迫地依賴那些根本用不上的方法。我只好把介面拆開，用組合搞定，組合是比較推薦的方式。
public
inte***ce
animal
public
inte***ce
yell
public
class
dogimplements
animal, yell
public
void
drink
() @override
public
void
yell
()}
就是說：乙個類對自己依賴的類知道的越少越好。也就是說無論被依賴的類多麼複雜，都應該將邏輯封裝在方法的內部，通過public方法提供給外部。這樣當被依賴的類變化時，才能最小的影響該類。
最少知道原則的另乙個表達方式是：只與直接的朋友通訊。類之間只要有耦合關係，就叫朋友關係。耦合分為依賴、關聯、聚合、組合等。我們稱出現為成員變數、方法引數、方法返回值中的類為直接朋友。區域性變數、臨時變數則不是直接的朋友。我們要求陌生的類不要作為區域性變數出現在類中。
直接丟擲定義吧
開閉原則：乙個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉感覺這個原則容易看懂，最難做到。白話就是不要改你以前寫的**，你應該加一些**去擴充套件原來的功能，來實現新的需求。好處很好理解，改原來的**很容易影響原來的功能，特別是接手別人的**，不理解原先業務場景的情況下。關於『不要動之前的**』感覺槽點無數啊，看自己寫的**想吐有木有？別人的**簡直...?之前**會想到會有這種鬼需求？....... 範圍
建立型結構型
行為型類
factory method（工廠方法）
adapter(類) （介面卡）
interpreter（直譯器）
template method（模版方法）
物件abstract factory（抽象工廠）
builder（建造者）
prototype（原型）
singleton（單例）
adapter(物件)（介面卡）
bridge（橋接）
composite（組合）
decorator（裝飾者）
façade（外觀）
flyweight（享元）
proxy（**）
chain of responsibility（職責鏈）
command（命令）
iterator（迭代器）
mediator（中介者）
memento（備忘錄）
observer（觀察者）
state（狀體）
strategy（策略）
visitor（訪問者）
再細點分類：
範圍建立型
結構型行為型
物件建立
singleton（單例）
prototype（原型）
factory method（工廠方法）
abstract factory（抽象工廠）
builder（建造者）
介面適配
adapter（介面卡）
bridge（橋接）
façade（外觀）
物件去耦
mediator（中介者）
observer（觀察者）
抽象集合
composite（組合）
iterator（迭代器）
行為擴充套件
decorator（裝飾）
visitor（訪問者）
chain of responsibility（職責鏈）
演算法封裝
template method（模板方法）
strategy（策略）
command
效能與物件訪問
flyweight（享元）
proxy（**）
物件狀態
memento（備忘錄）
state（狀態）
其它interpreter（直譯器）
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
參考文章 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放，對修改關閉。...