看了設計模式,最後看的總是感覺他們有很大的相似之處,就像是世界上萬事萬物都有其生存法則一樣.仔細分析其實設計模式都是圍繞一條主線來的。這就是設計模式的原則。你可以把設計原則比作一門語言。把設計模式當作這門語言編寫出來的程式。如果你精通了語言剩下的編碼就是很簡單的事情了.設計模式中的體現uml圖對於層出不窮的設計模式,比如gof的23種設計模式,mvc模式,到底應該怎樣去學習,如果我們單純的乙個乙個的研究設計模式本身,那麼只能是越看越多,越來越亂.其實我們只要抓住設計模式的原則,就能很清楚的分析出它為什麼會這麼做.
設計模式原則再加上oop三大屬性(封裝,繼承,多型)我們就能很清楚的理解設計模式.
首先提出一下什麼是設計模式:
模式：每乙個模式描述了乙個在我們周圍不斷重**生的問題，以及該問題的解決方案的核心。
這是關於模式最經典的定義，作者是建築大師christopher alexander。如果是第一次看到這句話，多數人會覺得有些抽象難懂。其實「模式」兩個字只是乙個代號，就像我叫李守巨集，如果我改叫李四也沒什麼問題，只是我更喜歡李守巨集這個名字，所以從christopher開始，有了「模式」這個詞，人們也都把關於「重**生的問題的描述和解決辦法」統稱為模式。
「模式」這個詞是不侷限於軟體開發行業的，它幾乎無處不在，它其實就是一種經驗的積累，就象大多數人的教育經歷都是從小學到初中再到高中再到大學，這也是一種模式，是中國的教育模式；現在越來越火的出國熱，也是另一種模式，海外留學模式。因為gof的《設計模式：可復用物件導向軟體的基礎》一書描述的23種經典設計模式，奠定了模式在軟體行業的地位，從此人們提到「設計模式」就是默指「物件導向設計模式」，但是模式絕對不侷限於軟體行業，即使在軟體行業，也不侷限於gof描述的23種設計模式，例如我們常用的mvc等。
因為模式是一種經驗的積累和總結，所以通過模式，我們可以站在巨人的肩膀上去思考問題、解決問題，熟練使用設計模式可以提高我們的工作效率，改善產品質量，最終帶來經濟效益。因此對於任何想開發出靈活高效、健壯的軟體產品的個人或團體，熟練掌握並正確使用設計模式都是必須掌握的基本技能。
談到設計模式,不能不說一下grasp (職責分配原則),這個比模式更重要.我將再後邊接著來分析.
下面我來分析一下設計模式原則,以及在設計模式中的體現.主要參考:程杰 《大話設計模組》(這裡用dh代替) 和justin tech 的部落格.
一:設計模式的核心原則是:"開-閉"原則( open - closed principle 縮寫:ocp ),一切的一切都是圍繞著"開-閉"原則展開的
開閉原則:說軟體實體(類,模組,函式等)應該可以擴充套件,但是不可以修改 [dh].
意思是,在乙個系統中,對於擴充套件是開放的,對於修改是關閉的,乙個好的系統是在不修改源**的情況下,可以擴充套件你的功能..而實現開閉原則的關鍵就是抽象化.
在"開-閉"原則中,不允許修改的是抽象的類或者介面,允許擴充套件的是具體的實現類,抽象類和介面在"開-閉"原則中扮演著極其重要的角色..即要預知可能變化的需求.又預見所有可能已知的擴充套件..所以在這裡"抽象化"是關鍵!
當然對於修改,我們不可能完全避免,也不可能完全預知到未來的變化.所以我們要做到盡量去不要修改,或者少的修改就能達到我們的目標.
例如:對於簡單工廠模式.我們有能力預知到未來可能新增計算,所以,我們將運算類抽象出來.為了以後方便擴充套件.這裡的運算類是不可以修改的.但是對於他的子類.我們是可以擴充套件的.
二:依賴倒轉原則a:高層模組不應該依賴底層模組 b:抽象不應該依賴細節,細節應該依賴抽象[dh]
就是說要依賴抽象,而不要依賴具體的實現..如果說開閉原則是目標,依賴倒轉原則是到達"開閉"原則的手段..如果要達到最好的"開閉"原則,就要盡量的遵守依賴倒轉原則..可以說依賴倒轉原則是對"抽象化"的最好規範!!
通俗的說就是只有抽象的東西才是最穩定的，也就是說，我們依賴的是它的穩定。如果將來「抽象」也不穩定了，那麼誰穩定我跟誰，其實說白了不就是傍大款嗎！
比如我們在觀察者模式中(observer)這裡的通知者,就不應該是具體.因為我們應當考慮到如果前台那裡換了人怎麼辦?這個通知還可以是其他人通知.比如老闆要通知去做某件事怎麼辦?為了讓大家都能用這個通知.所以要設定成抽象的.這裡的前台,老闆都要依賴這個通知.也就是說.細節要依賴抽象.
三:黎克特制代換原則:定義:子型別必須能夠替換它們的父型別[dh]
這個原則是對繼承的乙個約束,也就是說,繼承中子類嚴格滿足"is a "的關係.這裡我個人有深刻的體會.尤其是在看別人的uml圖的時候.
對你幫助很大.當你看到乙個繼承的時候.要習慣性的把他的父類和子類看成乙個整體.這樣會有助於你去理解各個類之間的關係.因為根據
黎克特制代換原則.父類出現的地方子類也可以出現.
比如我們再看工廠模式的時候,你看到有的書上簡單工廠類關聯著運算父類.有的書上是關聯著運算類的子類.其實仔細想想他們都沒有錯,
父類和子類的關聯都是一樣的,父類能出現的地方,子類就可以出現.
在設計模式中的體現:
設計模式中所有繼承都能體現著這一原則.我舉乙個不符合原則的例子.
四:單一職能原則定義:就乙個類而言,應該僅有乙個引起他變化的原因[dh]
也就是說，不要把變化原因各不相同的職責放在一起，因為不同的變化會影響到不相干的職責。再通俗一點地說就是，不該你管的事情你不要管，
管好自己的事情就可以了，多管閒事害了自己也害了別人。(當然這裡說的多管閒事跟見義勇為是兩回事，我們提倡見義勇為！)
這個就是說,乙個類盡量做到了功能單一,比如在mvc中,判斷資料的類和新增資料庫的類一定要分開.單一職能的不是說職能多了我們實現不了,是
為了後期的測試維護,每個類的很單一,我們找錯誤的時候就可以一步到位.新增新的功能的時候,也不用牽扯到很多的類.
在設計模式中的體現:
烤肉者就管烤肉,他也不管收錢,也不管記錄.這樣把"地攤"上的烤肉者分成服務員和烤肉的人.讓職責單一.不容易出錯.上邊的都是幾個原則,下面介紹兩個法則:
(1)迪公尺特法則:系統中的類,盡量不要與其他類互相作用,減少類之間的耦合度,因為在你的系統中,擴充套件的時候,你可能需要修改這些類,而類與類
之間的關係,決定了修改的複雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小..例如a類依賴b類,
則b類依賴c類,當你在修改a類的時候,你要考慮b類是否會受到影響,而b類的影響是否又會影響到c類..如果此時c類再依賴d類的話,呵呵,
我想這樣的修改有的受了..
(2)介面隔離法則:這個法則與迪公尺特法則是相通的,迪公尺特法則是目的,而介面隔離法則是對迪公尺特法則的規範..為了做到盡可能小的耦合性,我們
需要使用介面來規範類,用介面來約束類.要達到迪公尺特法則的要求,最好就是實現介面隔離法則,實現介面隔離法則,你也就滿足了迪公尺特法則...
這裡也體現了乙個依賴原則,要盡量依賴抽象,不要依賴具體.
設計模式中的體現:高層模組依靠介面和底層模組依賴.
總結:學習設計模式的基礎就是理解設計原則,只用理解了這些原則,加上oo的三大特性.再去體會設計模式滿足那些原則.最後達到你可以運用這些原則來寫出自己的設計模式來,這才是最高境界.我在看了一遍大話設計模式以後,將其中的思想總結出來.和大家分享.
設計模式 設計模式原則
1 單一職責原則 srp 乙個類應當只有乙個引起其變化的原因。使用單一職責原則的好處有 1 類的複雜性降低 2 可讀性提高 3 可維護性提高 4 變更引起的風險降低 2 黎克特制替換原則 lsp 在使用父類的地方，可以使用其子類替換。黎克特制替換原則的含義 1 子類必須完全實現父類的方法 2 子類可...
設計模式 設計原則
1.單一職責原則 single responsibility principle，簡稱srp 就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到...
設計模式 設計原則
description 這是本人學習 設計模式之禪 的筆記 設計原則 一 單一職責 應該有且僅有乙個原因讓乙個類發生變更。這個原則目的是要讓介面的職責分明，結構清晰。優點 類的複雜度降低，可讀性提高，變更風險低，可維護性提高。二 黎克特制替換 通俗一點就是父類存在的地方，可以替換為子類，而程式的行為...