面向?qū)ο竽Ｊ皆O(shè)計.docx

第一張PPT1. 什么是設(shè)計模式？設(shè)計模式是對軟件工程是的基本要求 設(shè)計模式在生活中隨處可見在房屋建設(shè)上不同的地區(qū)房屋建設(shè)有不同的風(fēng)格，中式風(fēng)格或歐式風(fēng)格，不同的風(fēng)格有不同的框架核結(jié)構(gòu) 不同的武功也有不同的招式，不同的模式 模式不是死的 是經(jīng)驗豐富的大師有自己的模式 我們應(yīng)該理解模式從而創(chuàng)造自己的模式這是關(guān)于模式最經(jīng)典的定義，作者是建筑大師Christopher Alexander。(克里斯托夫亞歷山大, ,其卓越才能與貢獻(xiàn)不僅表現(xiàn)模式：每一個模式描述了一個在我們周圍不斷重復(fù)發(fā)生的問題，以及該問題的解決方案的核心。于建筑,在室內(nèi)、計算機、信息產(chǎn)業(yè)結(jié)構(gòu)、家具設(shè)計甚至哲學(xué)方面都卓有建樹。他被廣泛認(rèn)為是計算機科學(xué)模式語言運動之父其創(chuàng)立的“模式語言”理論不僅在建筑設(shè)計方法論研究上具有劃時代的意義,也對計算機等領(lǐng)域產(chǎn)生了重大影響。許多人質(zhì)疑Alexander是站在建筑學(xué)的角度，其觀點并未被廣泛接受。“四人幫”的著作設(shè)計模式對軟件模式的影響比Alexander的著作要大得多，而設(shè)計模式一書的四位作者中的三位在寫書之前都沒有讀過Alexander的著作。建筑學(xué)本科學(xué)歷和數(shù)學(xué)碩士學(xué)歷。在哈佛研讀他的博士學(xué)位)如果是第一次看到這句話，多數(shù)人會覺得有些抽象難懂。其實“模式”兩個字只是一個代號，就像我叫李守宏，如果我改叫李四也沒什么問題，只是我更喜歡李守宏這個名字，所以從Christopher開始，有了“模式”這個詞，人們也都把關(guān)于“重復(fù)發(fā)生的問題的描述和解決辦法”統(tǒng)稱為模式。“模式”這個詞是不局限于軟件開發(fā)行業(yè)的，它幾乎無處不在，它其實就是一種經(jīng)驗的積累，就象大多數(shù)人的教育經(jīng)歷都是從小學(xué)到初中再到高中再到大學(xué)，這也是一種模式，是中國的教育模式；現(xiàn)在越來越火的出國熱，也是另一種模式，海外留學(xué)模式。因為GOF的設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)一書描述的23種經(jīng)典設(shè)計模式，奠定了模式在軟件行業(yè)的地位，從此人們提到“設(shè)計模式”就是默指“面向?qū)ο笤O(shè)計模式”，但是模式絕對不局限于軟件行業(yè)，即使在軟件行業(yè)，也不局限于GOF描述的23種設(shè)計模式，例如我們常用的MVC等。因為模式是一種經(jīng)驗的積累和總結(jié)，所以通過模式，我們可以站在巨人的肩膀上去思考問題、解決問題，熟練使用設(shè)計模式可以提高我們的工作效率，改善產(chǎn)品質(zhì)量，最終帶來經(jīng)濟效益。因此對于任何想開發(fā)出靈活高效、健壯的軟件產(chǎn)品的個人或團體，熟練掌握并正確使用設(shè)計模式都是必須掌握的基本技能。2.設(shè)計模式的優(yōu)點使用設(shè)計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設(shè)計模式于己于他人于系統(tǒng)都是多贏的，設(shè)計模式使代碼編制真正工程化，設(shè)計模式是軟件工程的基石脈絡(luò)，如同大廈的結(jié)構(gòu)一樣。，設(shè)計模式有助于對框架結(jié)構(gòu)的理解，成熟的框架通常使用了多種設(shè)計模式,如果你熟悉這些設(shè)計模式，毫無疑問，你將迅速掌握框架的結(jié)構(gòu)，我們一般開發(fā)者如果突然接觸EJBJ2EE等框架，會覺得特別難學(xué)，難掌握，那么轉(zhuǎn)而先掌握設(shè)計模式，無疑是給了你剖析EJB或J2EE系統(tǒng)的一把利器。3 。模式的要素單一職責(zé)原則告訴我們實現(xiàn)類要職責(zé)單一；里氏替換原則告訴我們不要破壞繼承體系；依賴倒置原則告訴我們要面向接口編程；接口隔離原則告訴我們在設(shè)計接口的時候要精簡單一；迪米特法則告訴我們要降低耦合。而開閉原則是總綱，他告訴我們要對擴展開放，對修改關(guān)閉。設(shè)計模式的原則看了設(shè)計模式,最后看的總是感覺他們有很大的相似之處,就像是世界上萬事萬物都有其生存法則一樣.仔細(xì)分析其實設(shè)計模式都是圍繞一條主線來的。這就是設(shè)計模式的原則。你可以把設(shè)計原則比作一門語言。把設(shè)計模式當(dāng)作這門語言編寫出來的程序。如果你精通了語言剩下的編碼就是很簡單的事情了.對于層出不窮的設(shè)計模式,比如Gof的23種設(shè)計模式,MVC模式,到底應(yīng)該怎樣去學(xué)習(xí),如果我們單純的一個一個的研究設(shè)計模式本身,那么只能是越看越多,越來越亂.其實我們只要抓住設(shè)計模式的原則,就能很清楚的分析出它為什么會這么做.下面我來分析一下設(shè)計模式原則,以及在設(shè)計模式中的體現(xiàn)一:設(shè)計模式的核心原則是:開-閉原則( Open - Closed Principle 縮寫:OCP ),一切的一切都是圍繞著開-閉原則展開的開閉原則:說軟件實體(類,模塊,函數(shù)等)應(yīng)該可以擴展,但是不可以修改 DH.意思是,在一個系統(tǒng)中,對于擴展是開放的,對于修改是關(guān)閉的,一個好的系統(tǒng)是在不修改源代碼的情況下,可以擴展你的功能.而實現(xiàn)開閉原則的關(guān)鍵就是抽象化.在開-閉原則中,不允許修改的是抽象的類或者接口,允許擴展的是具體的實現(xiàn)類,抽象類和接口在開-閉原則中扮演著極其重要的角色.即要預(yù)知可能變化的需求.又預(yù)見所有可能已知的擴展.所以在這里抽象化是關(guān)鍵!當(dāng)然對于修改,我們不可能完全避免,也不可能完全預(yù)知到未來的變化.所以我們要做到盡量去不要修改,或者少的修改就能達(dá)到我們的目標(biāo).例如:對于簡單工廠模式.我們有能力預(yù)知到未來可能添加計算,所以,我們將運算類抽象出來.為了以后方便擴展.這里的運算類是不可以修改的.但是對于他的子類.我們是可以擴展的.二:依賴倒轉(zhuǎn)原則A:高層模塊不應(yīng)該依賴底層模塊 B:抽象不應(yīng)該依賴細(xì)節(jié),細(xì)節(jié)應(yīng)該依賴抽象DH就是說要依賴抽象,而不要依賴具體的實現(xiàn).如果說開閉原則是目標(biāo),依賴倒轉(zhuǎn)原則是到達(dá)開閉原則的手段.如果要達(dá)到最好的開閉原則,就要盡量的遵守依賴倒轉(zhuǎn)原則.可以說依賴倒轉(zhuǎn)原則是對抽象化的最好規(guī)范!通俗的說就是只有抽象的東西才是最穩(wěn)定的，也就是說，我們依賴的是它的穩(wěn)定。如果將來“抽象”也不穩(wěn)定了，那么誰穩(wěn)定我跟誰，其實說白了不就是傍大款嗎！比如我們在觀察者模式中(Observer)這里的通知者,就不應(yīng)該是具體.因為我們應(yīng)當(dāng)考慮到如果前臺那里換了人怎么辦?這個通知還可以是其他人通知.比如老板要通知去做某件事怎么辦?為了讓大家都能用這個通知.所以要設(shè)置成抽象的.這里的前臺,老板都要依賴這個通知.也就是說.細(xì)節(jié)要依賴抽象.三:里氏代換原則:定義:子類型必須能夠替換它們的父類型DH這個原則是對繼承的一個約束,也就是說,繼承中子類嚴(yán)格滿足is a 的關(guān)系.這里我個人有深刻的體會.尤其是在看別人的UML圖的時候.對你幫助很大.當(dāng)你看到一個繼承的時候.要習(xí)慣性的把他的父類和子類看成一個整體.這樣會有助于你去理解各個類之間的關(guān)系.因為根據(jù)里氏代換原則.父類出現(xiàn)的地方子類也可以出現(xiàn).比如我們再看工廠模式的時候,你看到有的書上簡單工廠類關(guān)聯(lián)著運算父類.有的書上是關(guān)聯(lián)著運算類的子類.其實仔細(xì)想想他們都沒有錯,父類和子類的關(guān)聯(lián)都是一樣的,父類能出現(xiàn)的地方,子類就可以出現(xiàn).在設(shè)計模式中的體現(xiàn):設(shè)計模式中所有繼承都能體現(xiàn)著這一原則.我舉一個不符合原則的例子.四:單一職能原則再通俗一點地說就是，不該你管的事情你不要管，管好自己的事情就可以了，多管閑事害了自己也害了別人。(當(dāng)然這里說的多管閑事跟見義勇為是兩回事，我們提倡見義勇為！)這個就是說,一個類盡量做到了功能單一,比如在mvc中,判斷數(shù)據(jù)的類和添加數(shù)據(jù)庫的類一定要分開.單一職能的不是說職能多了我們實現(xiàn)不了,是為了后期的測試維護(hù),每個類的很單一,我們找錯誤的時候就可以一步到位.添加新的功能的時候,也不用牽扯到很多的類.在設(shè)計模式中的體現(xiàn):烤肉者就管烤肉,他也不管收錢,也不管記錄.這樣把地攤上的烤肉者分成服務(wù)員和烤肉的人.讓職責(zé)單一.不容易出錯.上邊的都是幾個原則,下面介紹兩個法則:(1)迪米特法則:系統(tǒng)中的類,盡量不要與其他類互相作用,減少類之間的耦合度,因為在你的系統(tǒng)中,擴展的時候,你可能需要修改這些類,而類與類之間的關(guān)系,決定了修改的復(fù)雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小.例如A類依賴B類,則B類依賴C類,當(dāng)你在修改A類的時候,你要考慮B類是否會受到影響,而B類的影響是否又會影響到C類.如果此時C類再依賴D類的話,呵呵,(2)接口隔離法則:這個法則與迪米特法則是相通的,迪米特法則是目的,而接口隔離法則是對迪米特法則的規(guī)范.為了做到盡可能小的耦合性,我們需要使用接口來規(guī)范類,用接口來約束類.要達(dá)到迪米特法則的要求,最好就是實現(xiàn)接口隔離法則,實現(xiàn)接口隔離法則,你也就滿足了迪米特法則.這里也體現(xiàn)了一個依賴原則,要盡量依賴抽象,不要依賴具體.設(shè)計模式中的體現(xiàn):高層模塊依靠接口和底層模塊依賴.設(shè)計模式分為三種類型，共23種。一， 有一次我買了一個我很喜歡的杯子，然后我不管喝水，喝茶，還是喝酒，都用這一個杯子。此杯子在具有唯一性。于是我創(chuàng)建這個杯子的時候就想到用單例模式由于有些飲料需要細(xì)細(xì)品嘗，比如說咖啡，于是我又買來了勺子，但是由于勺子這東西不是經(jīng)常用，有時候不見了忘記了，每次都重新買一把，后來我就有了幾把勺子（單例模式擴展用途，控制用戶生成類的個數(shù)）：不知為何我和杯具結(jié)下了不解之緣，后來做了杯具商人，專門買各種各樣的杯具生意，我要生產(chǎn)一批不同類型的杯具，于是乎我找到了一個專門生產(chǎn)杯具的工廠-簡單工廠盛水-玻璃杯盛水-木杯 盛水-塑料杯); 盛水-金屬杯簡單工廠需要我口頭告訴工廠我生產(chǎn)的類型，由于訂單經(jīng)常變，容易混淆杯具的類型，于是乎后來我們簽訂和合約，每次需要不同類型杯具的時候，我就將需要杯具的類型寫在訂單上(對應(yīng)程序的配置文件中)-反射工廠：五，隨著生意越做越大，訂單的處理也變得不是很方便，一個工廠處理了所有的生產(chǎn)杯具的工作，簡單工廠已經(jīng)力不從心了，此時我們不得不針對每種不同的杯具選擇不同的工廠為我們生產(chǎn)-工廠方法：六，生意是越做越大，光賣杯具已經(jīng)滿足不了我的胃口，于是乎想到賣勺子搭配，勺子和杯子的搭配這個得講究，玻璃對玻璃，木頭對木頭這樣子搭配，顯得統(tǒng)一，但是如果勺子杯子分不同的廠來生產(chǎn)，這樣子在我們貨源中就會產(chǎn)生很多很