設計模式原則詳解
這篇文章
,不需要你一次就看懂
,如果你真的能一次都看懂
,我想設計模式對於你來說已經沒什麼難度了
..因為設計模式就是要體現這些原則的
,你可以把設計原則看做是一門語言
,設計模式是由這些語言編碼的程式
..你既然已經明白
,精通了語言
,剩下的編碼自然是很簡單的事情
,編碼的越多則經驗越多
,經驗越多則對原則的理解就越深
...這是乙個
學習領悟
的過程..
我希望這篇文章能幫助新人感受到
設計模式的樂趣
,避免重複編碼
....
減少勞動量
..如果你能在用心靜靜的體會文章的每個字
,每段話的意思
,這樣可以避免走很多彎路
...我以前學習設計模式的時候
,就是因為忽略了原則
,憑著感覺
,看著書來學習設計模式
,結果就是知其然而不知其所以然
....
如果你是初學設計模式
,再了解了
oop的三大原則(封套
,繼承,多型
)之後,請反覆的結合原則
,來學習設計模式
..這樣可以達到事半功倍的效果
...設計模式的核心原則是:"開
-閉"原則
( open - closed principle
縮寫:ocp ),
一切的一切都是圍繞著"開
-閉"原則展開的
..意思是
,在乙個系統中
,對於擴充套件是開放的
,對於修改是關閉的
,乙個好的系統是在不修改源**的情況下
,可以擴充套件你的功能
..而實現開閉原則的關鍵就是抽象化.在
"開-閉
"原則中
,不允許修改的是抽象的類或者介面
,允許擴充套件的是具體的實現類
,抽象類和介面在"開
-閉"原則中扮演著極其重要的角色
..即要預知可能變化的需求
.又預見所有可能已知的擴充套件
..所以在這裡
"抽象化
"是關鍵
!!!
可變性的封閉原則
:找到系統的可變因素
,將它封裝起來
..這是對"開
-閉"原則最好的實現
..不要把你的可變因素放在多個類中
,或者散落在程式的各個角落
..你應該將可變的因素
,封套起來
..並且切忌不要把所用的可變因素封套在一起
..最好的解決辦法是
,分塊封套你的可變因素
!!避免超大類
,超長類
,超長方法的出現
!!給你的程式增加藝術氣息
,將程式藝術化是我們的目標
!!
黎克特制代換原則
:任何基類可以出現的地方
,子類也可以出現
..如果你通讀過
程式設計思想
>,
我想你應該明白這個原則
,在書中
,bruce eckel
大師用了大量的章節來講解
"向上轉型"和
"向下轉型
",我想目的很清楚
,不僅是要你明白類的型別
,更重要的是要你明白父類與子類的關係
..依賴倒轉原則
:要依賴抽象
,而不要依賴具體的實現
..如果說開閉原則是目標
,依賴倒轉原則是到達"開閉
"原則的手段
..如果要達到最好的"開閉
"原則,就要盡量的遵守依賴倒轉原則
..可以說依賴倒轉原則是對
"抽象化
"的最好規範
!!我個人感覺
,依賴倒轉原則也是黎克特制代換原則的補充
..你理解了黎克特制代換原則
,再來理解依賴倒轉原則應該是很容易的
..合成
/聚合原則
:要盡量使用合成
/聚合原則
,而不是繼承關係達到軟體復用的目的
..此原則和黎克特制代換原則氏相輔相成的
,兩者都是具體實現"開
-閉"原則的規範
..違反這一原則
:就無法實現"開
-閉"原則
..先來看看什麼是合成
,什麼是聚合.
什麼是合成?合成
:是指乙個整體對依託他而存在的關係,例如
:乙個人對他的房子和家具
,其中他的房子和家具是不能被共享的
,因為那些東西都是他自己的
..並且人沒了
,這個也關係就沒了
..這個例子就好像
,烏雞百鳳丸這個產品
,它是有烏雞和上等藥材合成而來的一樣
..也比如網路遊戲中的**裝備合成一樣
,多種東西合併為一種超強的東西一樣
..什麼是聚合?聚合
:聚合是比合成關係的一種更強的依賴關係
,聚合是乙個整體對個體的部分,例如
,乙個賓士
s360汽車,
對賓士s360引擎,
賓士s360
輪胎的關係
..這些關係就是帶有聚合性質的
..因為賓士
s360
引擎和賓士
s360
輪胎他們只能被賓士
s360
汽車所用
,離開了賓士
s360汽車,
它們就失去了存在的意義
..在我們的設計中
,這樣的關係不應該頻繁出現
..這樣會增大設計的耦合度
..明白了合成和聚合關係
,再來理解合成
/聚合原則應該就清楚了
..要避免在系統設計中出現
,乙個類的繼承層次超過3次
..如果這樣的話
,可以考慮重構你的**
,或者重新設計結構
..當然最好的辦法就是考慮使用合成
/聚合原則
...迪公尺特法則
:系統中的類
,盡量不要與其他類互相作用
,減少類之間的耦合度
,因為在你的系統中
,擴充套件的時候
,你可能需要修改這些類
,而類與類之間的關係
,決定了修改的複雜度
,相互作用越多
,則修改難度就越大,反之
,如果相互作用的越小
,則修改起來的難度就越小
..例如
a類依賴b類
,則b類依賴c類
,當你在修改
a類的時候
,你要考慮
b類是否會受到影響,而
b類的影響是否又會影響到c類
..如果此時
c類再依賴
d類的話,呵呵
,我想這樣的修改有的受了
..介面隔離法則
:這個法則與迪公尺特法則是相通的
,迪公尺特法則是目的
,而介面隔離法則是對迪公尺特法則的規範
..為了做到盡可能小的耦合性
,我們需要使用介面來規範類
,用介面來約束類
.要達到迪公尺特法則的要求
,最好就是實現介面隔離法則
,實現介面隔離法則
,你也就滿足了迪公尺特法則
...如果你能看這裡
,說明你已經對這些原則了有了感性的認識
..這些原則是設計模式的核心
,如果不能充分理解這些原則
,是很難理解好設計模式的
..
如果第一遍看不懂
,沒關係
,請反覆揣摩,細讀每個字,每句話..對於這些原則
,我也是看了
n*n遍才明白的
(這期間也沒任何人指點過我
,更每人講的這麼細
,獎勵自己一下先,汗啊
)..我推薦看完原則之後
,請看設計模式
,看兩三個模式
,然後理解一下
,自己動手把模式實現出來
,再回頭來看原則
,你會感覺
,你的模式一定是滿足了其中的某些原則
!!這是必然的
!!只要你理解了原則
,設計模式不難理解
..就好比
,有了內功基礎的你
,再來學習刀,劍
,槍這些**的時候
,要比那些直接學習刀,槍
,劍的人
,快很多
,效果也好很多
...如果你要了解設計模式
,在園子裡也有
n多好的設計模式文章
,精華區的設計模式區
..有很多都是不錯的介紹文章
..另外近段時間
,我也在發表關於設計模式的心得
..如果有興趣
,可以關注一下
...
設計模式原則詳解
設計模式原則詳解 這篇文章,不需要你一次就看懂,如果你真的能一次都看懂,我想設計模式對於你來說已經沒什麼難度了.因為設計模式就是要體現這些原則的,你可以把設計原則看做是一門語言,設計模式是由這些語言編碼的程式.你既然已經明白,精通了語言,剩下的編碼自然是很簡單的事情,編碼的越多則經驗越多,經驗越多則...
設計模式原則詳解
這篇文章,不需要你一次就看懂,如果你真的能一次都看懂,我想設計 模式對於你來說已經沒什麼難度了.因為設計模式就是要體現這些原則的,你可以把設計原則看做是一門語言,設計模式是由這些語言編碼的程式.你既然已經明白,精通了語言,剩下的編碼自然是很簡單的事情,編碼的越多則經驗越多,經驗越多則對原則的理解就越...
設計模式原則詳解
這篇文章,不需要你一次就看懂,如果你真的能一次都看懂,我想設計模式對於你來說已經沒什麼難度了.因為設計模式就是要體現這些原則的,你可以把設計原則看做是一門語言,設計模式是由這些語言編碼的程式.你既然已經明白,精通了語言,剩下的編碼自然是很簡單的事情,編碼的越多則經驗越多,經驗越多則對原則的理解就越深...