談到設計模式,不能不說一下grasp (職責分配原則),這個比模式更重要.我將再後邊接著來分析.
下面我來分析一下設計模式原則,以及在設計模式中的體現.主要參考:程杰 《大話設計模組》(這裡用dh代替) 和justin tech 的部落格.
一:設計模式的核心原則是:"開-閉"原則( open - closed principle 縮寫:ocp ),一切的一切都是圍繞著"開-閉"原則展開的
開閉原則:說軟體實體(類,模組,函式等)應該可以擴充套件,但是不可以修改 [dh].
意思是,在乙個系統中,對於擴充套件是開放的,對於修改是關閉的,乙個好的系統是在不修改源**的情況下,可以擴充套件你的功能..而實現開閉原則的關鍵就是抽象化.
在"開-閉"原則中,不允許修改的是抽象的類或者介面,允許擴充套件的是具體的實現類,抽象類和介面在"開-閉"原則中扮演著極其重要的角色..即要預知可能變化的需求.又預見所有可能已知的擴充套件..所以在這裡"抽象化"是關鍵!
當然對於修改,我們不可能完全避免,也不可能完全預知到未來的變化.所以我們要做到盡量去不要修改,或者少的修改就能達到我們的目標.
例如:對於簡單工廠模式.我們有能力預知到未來可能新增計算,所以,我們將運算類抽象出來.為了以後方便擴充套件.這裡的運算類是不可以修改的.但是對於他的子類.我們是可以擴充套件的.
設計模式中的體現uml圖
二:依賴倒轉原則
a:高層模組不應該依賴底層模組 b:抽象不應該依賴細節,細節應該依賴抽象[dh]
就是說要依賴抽象,而不要依賴具體的實現..如果說開閉原則是目標,依賴倒轉原則是到達"開閉"原則的手段..如果要達到最好的"開閉"原則,就要盡量的遵守依賴倒轉原則..可以說依賴倒轉原則是對"抽象化"的最好規範!!
通俗的說就是只有抽象的東西才是最穩定的,也就是說,我們依賴的是它的穩定。如果將來「抽象」也不穩定了,那麼誰穩定我跟誰,其實說白了不就是傍大款嗎!
比如我們在觀察者模式中(observer)這裡的通知者,就不應該是具體.因為我們應當考慮到如果前台那裡換了人怎麼辦?這個通知還可以是其他人通知.比如老闆要通知去做某件事怎麼辦?為了讓大家都能用這個通知.所以要設定成抽象的.這裡的前台,老闆都要依賴這個通知.也就是說.細節要依賴抽象.
三:黎克特制代換原則:
定義:子型別必須能夠替換它們的父型別[dh]
這個原則是對繼承的乙個約束,也就是說,繼承中子類嚴格滿足"is a "的關係.這裡我個人有深刻的體會.尤其是在看別人的uml圖的時候.
對你幫助很大.當你看到乙個繼承的時候.要習慣性的把他的父類和子類看成乙個整體.這樣會有助於你去理解各個類之間的關係.因為根據
黎克特制代換原則.父類出現的地方子類也可以出現.
比如我們再看工廠模式的時候,你看到有的書上簡單工廠類關聯著運算父類.有的書上是關聯著運算類的子類.其實仔細想想他們都沒有錯,
父類和子類的關聯都是一樣的,父類能出現的地方,子類就可以出現.
在設計模式中的體現:
設計模式中所有繼承都能體現著這一原則.我舉乙個不符合原則的例子.
四:單一職能原則
定義:就乙個類而言,應該僅有乙個引起他變化的原因[dh]
也就是說,不要把變化原因各不相同的職責放在一起,因為不同的變化會影響到不相干的職責。再通俗一點地說就是,不該你管的事情你不要管,
管好自己的事情就可以了,多管閒事害了自己也害了別人。(當然這裡說的多管閒事跟見義勇為是兩回事,我們提倡見義勇為!)
這個就是說,乙個類盡量做到了功能單一,比如在mvc中,判斷資料的類和新增資料庫的類一定要分開.單一職能的不是說職能多了我們實現不了,是
為了後期的測試維護,每個類的很單一,我們找錯誤的時候就可以一步到位.新增新的功能的時候,也不用牽扯到很多的類.
在設計模式中的體現:
烤肉者就管烤肉,他也不管收錢,也不管記錄.這樣把"地攤"上的烤肉者分成服務員和烤肉的人.讓職責單一.不容易出錯.
上邊的都是幾個原則,下面介紹兩個法則:
(1)迪公尺特法則:系統中的類,盡量不要與其他類互相作用,減少類之間的耦合度,因為在你的系統中,擴充套件的時候,你可能需要修改這些類,而類與類
之間的關係,決定了修改的複雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小..例如a類依賴b類,
則b類依賴c類,當你在修改a類的時候,你要考慮b類是否會受到影響,而b類的影響是否又會影響到c類..如果此時c類再依賴d類的話,呵呵,
我想這樣的修改有的受了..
(2)介面隔離法則:這個法則與迪公尺特法則是相通的,迪公尺特法則是目的,而介面隔離法則是對迪公尺特法則的規範..為了做到盡可能小的耦合性,我們
需要使用介面來規範類,用介面來約束類.要達到迪公尺特法則的要求,最好就是實現介面隔離法則,實現介面隔離法則,你也就滿足了迪公尺特法則...
這裡也體現了乙個依賴原則,要盡量依賴抽象,不要依賴具體.
設計模式中的體現:高層模組依靠介面和底層模組依賴.
總結:學習設計模式的基礎就是理解設計原則,只用理解了這些原則,加上oo的三大特性.再去體會設計模式滿足那些原則.最後達到你可以運用這些原則來寫出自己的設計模式來,這才是最高境界.我在看了一遍大話設計模式以後,將其中的思想總結出來.和大家分享.
設計模式幾大原則
談到設計模式,不能不說一下grasp 職責分配原則 這個比模式更重要.我將再後邊接著來分析.下面我來分析一下設計模式原則,以及在設計模式中的體現.主要參考 程杰 大話設計模組 這裡用dh代替 和justin tech 的部落格.一 設計模式的核心原則是 開 閉 原則 open closed prin...
設計模式幾大原則
開閉原則 open close principle 對擴充套件開放,對修改封閉。該設計原則要求在程式要進行擴充套件的時候,不去修改原有 而是通過擴充套件新 來實現。這樣的程式 非常易於維護和公升級。單一原則 每個類應該實現單一的職責。如果某類多於乙個職責,就應該對其進行拆分。黎克特制替換原則 lis...
設計模式的幾大原則
單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當變化發生時,設計會遭受到竟想不到的破壞。開放 封閉原則 是說軟體實體 類 模組 函式等等 應該可以擴充套...