設(shè)計(jì)模式王維雄

1、軟件設(shè)計(jì)模式（軟件設(shè)計(jì)模式（design patternsdesign patterns） 可復(fù)用面向?qū)ο筌浖幕A(chǔ)內(nèi)部培訓(xùn) 王維雄等內(nèi)容概括1. 設(shè)計(jì)模式介紹2. 常用設(shè)計(jì)模式分別講（由簡入深）3. 案例4. 交流為什么要學(xué)習(xí)設(shè)計(jì)模式？成為牛人！ 為什么一個相似的功能，大牛一會兒就搞定，然后悠閑地品著下午茶逛淘寶；而自己加班加點(diǎn)搞到天亮還做不完。 為什么用戶提出需求變更后，大牛只需瀟灑地敲敲鍵盤，改改配置；而自己將代碼改了又改，刪了又建，幾乎暈厥，最后只能推翻重來。 為什么大牛寫完的程序測試上線后，幾乎完美運(yùn)行，用戶無懈可擊；而自己的程序bug重重，改好一個卻又引出另一個，按下葫蘆浮起瓢，幾

2、近崩潰。為什么要學(xué)習(xí)設(shè)計(jì)模式？復(fù)用解決方案: 通過復(fù)用已經(jīng)公認(rèn)的設(shè)計(jì),能夠在解決問題時取得先發(fā)優(yōu)勢.避免重蹈覆轍.您是是否也有類似疑慮:幾個項(xiàng)目下好。確定通用術(shù)語: 開發(fā)中的交流和協(xié)作都需要共同的詞匯其礎(chǔ)和對問題的共識.如果交流雙方都學(xué)習(xí)過設(shè)計(jì)模式交流起來就會十分的舒服.不知道你有沒有想表達(dá)又表達(dá)不清楚的設(shè)計(jì) 思路,或者自己表達(dá)得明白但對方又誤解了你的意思了呢?看了設(shè)計(jì)模式你也許可以找到你想要的答案。改善團(tuán)隊(duì)的溝通和個人學(xué)習(xí)。一個團(tuán)隊(duì)一起學(xué)習(xí)設(shè)計(jì)模式,有助于團(tuán)隊(duì)?wèi)?zhàn)斗力的提高。代碼更易于修改與維護(hù)。 因?yàn)樵O(shè)計(jì)模式都是久經(jīng)考驗(yàn)的解決方案,它們的結(jié)構(gòu)都是經(jīng)過長期的發(fā)展形成的，善于應(yīng)對變化。模式有助于

3、提高思考層次。學(xué)習(xí)模式后,就算不用模式中的方法，也會更好的采取更好的策略去解決問題。1.1 設(shè)計(jì)模式介紹 - 什么是設(shè)計(jì)模式？設(shè)計(jì)模式（design pattern）是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。1970年建筑設(shè)計(jì)大師亞力山大。軟件設(shè)計(jì)模式這個術(shù)語是在1990年代由erich gamma等4人引入，用來解決同一問題的不同表相。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設(shè)計(jì)模式于己于他人于系統(tǒng)都是多贏的，設(shè)計(jì)模式使代碼編制真正工程化，設(shè)計(jì)模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項(xiàng)目中合理的運(yùn)用設(shè)計(jì)模式可以完美的

4、解決很多問題，每種模式在現(xiàn)在中都有相應(yīng)的原理來與之對應(yīng)，每一個模式描述了一個在我們周圍不斷重復(fù)發(fā)生的問題，以及該問題的核心解決方案，這也是它能被廣泛應(yīng)用的原因。1.2 設(shè)計(jì)模式介紹 - 23種設(shè)計(jì)模式創(chuàng)建型創(chuàng)建對象時，不再由我們直接實(shí)例化對象；而是根據(jù)特定場景，由程序來確定創(chuàng)建對象的方式，從而保證更大的性能、更好的架構(gòu)優(yōu)勢。創(chuàng)建型模式主要有簡單工廠模式（并不是23種設(shè)計(jì)模式之一）、工廠方法、抽象工廠模式、單例模式、生成器模式、原型模式。結(jié)構(gòu)型用于幫助將多個對象組織成更大的結(jié)構(gòu)。結(jié)構(gòu)型模式主要有適配器模式、橋接模式、組合器模式、裝飾器模式、門面模式、亨元模式和代理模式。行為型用于幫助系統(tǒng)間各對象

5、的通信，以及如何控制復(fù)雜系統(tǒng)中流程。行為型模式主要有命令模式、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態(tài)模式、策略模式、模板模式和訪問者模式。1.3 設(shè)計(jì)模式的六大原則1、單一職責(zé)定義：不要存在多于一個導(dǎo)致類變更的原因。通俗的說，即一個類只負(fù)責(zé)一項(xiàng)職責(zé)。 問題由來：類t負(fù)責(zé)兩個不同的職責(zé)：職責(zé)p1，職責(zé)p2。當(dāng)由于職責(zé)p1需求發(fā)生改變而需要修改類t時，有可能會導(dǎo)致原本運(yùn)行正常的職責(zé)p2功能發(fā)生故障。解決方案：遵循單一職責(zé)原則。分別建立兩個類t1、t2，使t1完成職責(zé)p1功能，t2完成職責(zé)p2功能。這樣，當(dāng)修改類t1時，不會使職責(zé)p2發(fā)生故障風(fēng)險(xiǎn)；同理，當(dāng)修改t2時，也不會

6、使職責(zé)p1發(fā)生故障風(fēng)險(xiǎn)。遵循單一職責(zé)原的優(yōu)點(diǎn)有：可以降低類的復(fù)雜度，一個類只負(fù)責(zé)一項(xiàng)職責(zé)，其邏輯肯定要比負(fù)責(zé)多項(xiàng)職責(zé)簡單的多；提高類的可讀性，提高系統(tǒng)的可維護(hù)性；變更引起的風(fēng)險(xiǎn)降低，變更是必然的，如果單一職責(zé)原則遵守的好，當(dāng)修改一個功能時，可以顯著降低對其他功能的影響。1.3 設(shè)計(jì)模式的六大原則2、里氏代換原則（liskov substitution principle）子類可以擴(kuò)展父類的功能，但不能改變父類原有的功能定義1：如果對每一個類型為 t1的對象 o1，都有類型為 t2 的對象o2，使得以 t1定義的所有程序 p 在所有的對象 o1 都代換成 o2 時，程序 p 的行為沒有發(fā)生變化，

7、那么類型 t2 是類型 t1 的子類型。定義2：所有引用基類的地方必須能透明地使用其子類的對象。問題由來：有一功能p1，由類a完成。現(xiàn)需要將功能p1進(jìn)行擴(kuò)展，擴(kuò)展后的功能為p，其中p由原有功能p1與新功能p2組成。新功能p由類a的子類b來完成，則子類b在完成新功能p2的同時，有可能會導(dǎo)致原有功能p1發(fā)生故障。解決方案：當(dāng)使用繼承時，遵循里氏替換原則。類b繼承類a時，除添加新的方法完成新增功能p2外，盡量不要重寫父類a的方法，也盡量不要重載父類a的方法。1.3 設(shè)計(jì)模式的六大原則3、依賴倒置原則定義：高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴抽象。 問題由

8、來：類a直接依賴類b，假如要將類a改為依賴類c，則必須通過修改類a的代碼來達(dá)成。這種場景下，類a一般是高層模塊，負(fù)責(zé)復(fù)雜的業(yè)務(wù)邏輯；類b和類c是低層模塊，負(fù)責(zé)基本的原子操作；假如修改類a，會給程序帶來不必要的風(fēng)險(xiǎn)。解決方案：將類a修改為依賴接口i，類b和類c各自實(shí)現(xiàn)接口i，類a通過接口i間接與類b或者類c發(fā)生聯(lián)系，則會大大降低修改類a的幾率。實(shí)際需要做到如下3點(diǎn)：低層模塊盡量都要有抽象類或接口，或者兩者都有。變量的聲明類型盡量是抽象類或接口。使用繼承時遵循里氏替換原則。1.3 設(shè)計(jì)模式的六大原則4、接口隔離原則定義：客戶端不應(yīng)該依賴它不需要的接口；一個類對另一個類的依賴應(yīng)該建立在最小的接口上。

9、 問題由來：類a通過接口i依賴類b，類c通過接口i依賴類d，如果接口i對于類a和類b來說不是最小接口，則類b和類d必須去實(shí)現(xiàn)他們不需要的方法。解決方案：將臃腫的接口i拆分為獨(dú)立的幾個接口，類a和類c分別與他們需要的接口建立依賴關(guān)系。也就是采用接口隔離原則。接口設(shè)計(jì)原則：接口盡量小，但是要有限度。對接口進(jìn)行細(xì)化可以提高程序設(shè)計(jì)靈活性是不掙的事實(shí)，但是如果過小，則會造成接口數(shù)量過多，使設(shè)計(jì)復(fù)雜化。所以一定要適度。為依賴接口的類定制服務(wù)，只暴露給調(diào)用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定制服務(wù)，才能建立最小的依賴關(guān)系。提高內(nèi)聚，減少對外交互。使接口用最少的方法去完成最

10、多的事情。1.3 設(shè)計(jì)模式的六大原則5、迪米特法則（最少知道原則）定義：一個對象應(yīng)該對其他對象保持最少的了解。 問題由來：類與類之間的關(guān)系越密切，耦合度越大，當(dāng)一個類發(fā)生改變時，對另一個類的影響也越大。解決方案：盡量降低類與類之間的耦合。設(shè)計(jì)原則：只與直接的朋友通信，不要和陌生人說話。過分的使用該原則，將導(dǎo)致系統(tǒng)復(fù)雜度變大。所以在采用迪米特法則時要反復(fù)權(quán)衡，既做到結(jié)構(gòu)清晰，又要高內(nèi)聚低耦合。1.3 設(shè)計(jì)模式的六大原則6、開閉原則定義：一個軟件實(shí)體如類、模塊和函數(shù)應(yīng)該對擴(kuò)展開放，對修改關(guān)閉。 問題由來：在軟件的生命周期內(nèi)，因?yàn)樽兓?、升級和維護(hù)等原因需要對軟件原有代碼進(jìn)行修改時，可能會給舊代碼中引

11、入錯誤，也可能會使我們不得不對整個功能進(jìn)行重構(gòu)，并且需要原有代碼經(jīng)過重新測試。解決方案：當(dāng)軟件需要變化時，盡量通過擴(kuò)展軟件實(shí)體的行為來實(shí)現(xiàn)變化，而不是通過修改已有的代碼來實(shí)現(xiàn)變化。1.4 設(shè)計(jì)模式的六大原則總結(jié) 用抽象構(gòu)建框架，用實(shí)現(xiàn)擴(kuò)展細(xì)節(jié) 抽象合理（需求變更前瞻性和預(yù)見性），派生實(shí)現(xiàn)類 單一職責(zé)原則告訴我們實(shí)現(xiàn)類要職責(zé)單一； 里氏替換原則告訴我們不要破壞繼承體系； 依賴倒置原則告訴我們要面向接口編程； 接口隔離原則告訴我們在設(shè)計(jì)接口的時候要精簡單一； 迪米特法則告訴我們要降低耦合。 而開閉原則是總綱，他告訴我們要對擴(kuò)展開放，對修改關(guān)閉。1.4設(shè)計(jì)模式如何學(xué)習(xí)？大話設(shè)計(jì)模式 通俗易懂，筆法幽

12、默詼諧深入淺出設(shè)計(jì)模式軟件秘笈：設(shè)計(jì)模式那點(diǎn)事第一節(jié)課 3種工廠模式簡單/靜態(tài)工廠模式工廠方法模式抽象工廠模式 工廠模式主要是為創(chuàng)建對象提供過渡接口，以便將創(chuàng)建對象的具體過程屏蔽隔離起來，達(dá)到提高靈活性的目的。這三種模式從上到下逐步抽象，并且更具一般性。gof 在設(shè)計(jì)模式一書中將工廠模式分為兩類：工廠方法模式（factory method ）與抽象工廠模式（abstract factory）。將簡單工廠模式（simple factory）看為工廠方法模式的一種特例，兩者歸為一類，簡單工廠模式更像一種編程習(xí)慣，有必要講講。 3.1簡單工廠模式 代碼無錯就是優(yōu)？案例：計(jì)算器3.1簡單工廠模式 規(guī)范

13、后3.1簡單工廠模式 活字印刷-面向?qū)ο?易維護(hù)、擴(kuò)展、靈活 易復(fù)用（不是復(fù)制） 封裝3.1簡單工廠模式 松耦合，繼承3.1簡單工廠模式 創(chuàng)造實(shí)例、結(jié)構(gòu)圖3.1簡單工廠模式/生產(chǎn)產(chǎn)品的工廠類 public class productfactory public static product generateproduct(int which) /這個方法是static的 if (which=1) return new producta(); else if (which=2) return new productb(); /調(diào)用工廠方法 public client public method1

14、() productfactory.generateproduct(1); /抽象產(chǎn)品 public interface product . /具體產(chǎn)品a public producta implement product producta () /具體產(chǎn)品b public productb implement product productb () 3.1簡單工廠模式總結(jié) 不能滿足實(shí)現(xiàn)功能，應(yīng)時?？紤]簡練、易維護(hù)、擴(kuò)展、復(fù)用。 簡單工場實(shí)現(xiàn)了對責(zé)任的分割。 優(yōu)勢：讓對象的調(diào)用者和對象創(chuàng)建過程分離，當(dāng)對象調(diào)用者需要對象時，直接向工廠請求即可。從而避免了對象的調(diào)用者與對象的實(shí)現(xiàn)類以硬編碼方式耦合

15、，以提高系統(tǒng)的可維護(hù)性、可擴(kuò)展性。 缺陷：當(dāng)產(chǎn)品修改時，工廠類也要做相應(yīng)的修改，比如要增加一種操作類，如求m數(shù)的n次方，就得改case,修改原有類，違背了開放-封閉原則。3.2 工廠方法模式 解決簡單工廠模式的擴(kuò)展問題3.2 工廠方法模式 factory method請mm去麥當(dāng)勞吃漢堡，不同的mm有不同的口味，要每個都記住是一件煩人的事情，我一般采用factory method模式，帶著mm到服務(wù)員那兒，說“要一個漢堡”，具體要什么樣的漢堡呢，讓mm直接跟服務(wù)員說就行了。 工廠方法模式：核心工廠類不再負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，而是將具體創(chuàng)建的工作交給子類去做，成為一個抽象工廠角色，僅負(fù)責(zé)給出具體工

16、廠類必須實(shí)現(xiàn)的接口，而不接觸哪一個產(chǎn)品類應(yīng)當(dāng)被實(shí)例化這種細(xì)節(jié)。 3.2 工廠方法模式（4個角色）/抽象產(chǎn)品：產(chǎn)品 plant接口 public interface plant /具體產(chǎn)品：planta，plantb public class planta implements plant public planta () system.out.println(create planta !); public void dosomething() system.out.println( planta do something .); public class plantb implements

17、plant public plantb () system.out.println(create plantb !); public void dosomething() system.out.println( plantb do something .); / 抽象工廠（工廠方法的核心）：（工廠方法的核心）： public interface abstractfactory public plant createplant(); /具體工廠： public class factorya implements abstractfactory public plant createplant()

18、 return new planta(); public class factoryb implements abstractfactory public plant createplant() return new plantb(); /客戶端客戶端調(diào)用工廠方法 public client public method1() abstractfactory instancea = new factorya(); instancea.createplant(); abstractfactory instanceb = new factoryb(); instanceb.createplant()

19、; 3.2工廠方法模式總結(jié) 優(yōu)勢：克服了簡單工廠模式違背開放-封閉的原則，保持了封裝對象創(chuàng)建過程的優(yōu)點(diǎn)。 缺陷：當(dāng)增加產(chǎn)品時，就得增加一個產(chǎn)品工廠的類，增加額外的開發(fā)量。避免不了分支判斷的問題。 辦法：反射3.2 工廠方法模式和簡單工廠模式比較1. 結(jié)構(gòu)復(fù)雜度從這個角度比較，顯然簡單工廠模式要占優(yōu)。簡單工廠模式只需一個工廠類，而工廠方法模式的工廠類隨著產(chǎn)品類個數(shù)增加而增加，這無疑會使類的個數(shù)越來越多，從而增加了結(jié)構(gòu)的復(fù)雜程度。2.代碼復(fù)雜度代碼復(fù)雜度和結(jié)構(gòu)復(fù)雜度是一對矛盾，既然簡單工廠模式在結(jié)構(gòu)方面相對簡潔，那么它在代碼方面肯定是比工廠方法模式復(fù)雜的了。簡單工廠模式的工廠類隨著產(chǎn)品類的增加需要

20、增加很多方法（或代碼），而工廠方法模式每個具體工廠類只完成單一任務(wù)，代碼簡潔。3.客戶端編程難度工廠方法模式雖然在工廠類結(jié)構(gòu)中引入了接口從而滿足了ocp，但是在客戶端編碼中需要對工廠類進(jìn)行實(shí)例化。而簡單工廠模式的工廠類是個靜態(tài)類，在客戶端無需實(shí)例化，這無疑是個吸引人的優(yōu)點(diǎn)。4.管理上的難度擴(kuò)展。工廠方法模式完全滿足ocp，即它有非常良好的擴(kuò)展性。那是否就說明了簡單工廠模式就沒有擴(kuò)展性呢？答案是否定的。簡單工廠模式同樣具備良好的擴(kuò)展性擴(kuò)展的時候僅需要修改少量的代碼（修改工廠類的代碼）就可以滿足擴(kuò)展性的要求了。盡管這沒有完全滿足ocp，但我們認(rèn)為不需要太拘泥于設(shè)計(jì)理論。維護(hù)。假如某個具體產(chǎn)品類需要

21、進(jìn)行一定的修改，很可能需要修改對應(yīng)的工廠類。當(dāng)同時需要修改多個產(chǎn)品類的時候，對工廠類的修改會變得相當(dāng)麻煩（對號入座已經(jīng)是個問題了）。反而簡單工廠沒有這些麻煩，當(dāng)多個產(chǎn)品類需要修改是，簡單工廠模式仍然僅僅需要修改唯一的工廠類（無論怎樣都能改到滿足要求吧？大不了把這個類重寫）。3.2 改良方法：簡單工廠+反射添加類productc并實(shí)現(xiàn)iproduct接口，這是使用任何模式都無法避免的改變。在配置文件中多添加一條關(guān)于productc的配置信息。3.3 抽象工廠模式概念：供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。 案例：abstract factory 追mm少不了請吃飯了，

22、麥當(dāng)勞的套餐和肯德基的套餐都是mm愛吃的東西，雖然口味有所不同，但不管你帶mm去麥當(dāng)勞或肯德基，只管向服務(wù)員說“兩個b套餐”就行了。麥當(dāng)勞和肯德基就是b套餐的abstract factory, b套餐里含有漢堡, 雞翅和飲料. 麥當(dāng)勞或肯德基會根據(jù)b套餐的規(guī)格, 讓漢堡factory, 雞翅factory, 飲料factory分別生產(chǎn)對應(yīng)b套餐的材料.抽象工廠模式：客戶類和工廠類分開。消費(fèi)者任何時候需要某套產(chǎn)品集合時，只需向抽象工廠請求即可。抽象工廠會再向具體的工廠生產(chǎn)出符合產(chǎn)品集規(guī)格的產(chǎn)品.3.3 抽象工廠模式3.3 抽象工廠模式3.3 抽象工廠模式/ 抽象產(chǎn)品蔬菜： vegetable接口

23、 public interface vegetable /具體產(chǎn)品vegetablea，vegetablebpublic class vegetablea implements vegetable public vegetablea () public class vegetableb implements vegetable / 抽象產(chǎn)品水果： fruit接口 public interface fruit /具體產(chǎn)品fruita，fruitb public class fruita implements fruit public class fruitb implements fruit /

24、 /抽象工廠方法抽象工廠方法 public interface abstractfactory public plant createplant(); public fruit createfruit(); /具體工廠方法具體工廠方法 public class factorya implements abstractfactory public plant createvegetable() return new vegetablea(); public fruit createfruit() return new fruita(); public class factoryb impleme

25、nts abstractfactory public plant createvegetable() return new vegetableb(); public fruit createfruit() return new vegetableb(); 3.3 抽象工廠模式 優(yōu)缺點(diǎn) 支持多種觀感標(biāo)準(zhǔn)的用戶界面工具箱。游戲開發(fā)中的多風(fēng)格系列場景，比如道路，房屋，管道等。系統(tǒng)要在三個不同平臺上運(yùn)行，比如windows、linux、android上運(yùn)行，你會怎么設(shè)計(jì)？分別設(shè)計(jì)三套不同的應(yīng)用？通過抽象工廠模式屏蔽掉操作系統(tǒng)對應(yīng)用的影響。三個不同操作系統(tǒng)上的軟件功能、應(yīng)用邏輯、ui都應(yīng)該是非常類似，唯

26、一不同的是調(diào)用不同的工廠方法，由不同的產(chǎn)品類去處理與操作系統(tǒng)交互的信息 需要創(chuàng)建的對象是一系列相互關(guān)聯(lián)或相互依賴的產(chǎn)品族時，便可以使用抽象工廠模式。假如各個等級結(jié)構(gòu)中的實(shí)現(xiàn)類之間不存在關(guān)聯(lián)或約束，則使用多個獨(dú)立的工廠來對產(chǎn)品進(jìn)行創(chuàng)建，則更合適一點(diǎn)。3.3 抽象工廠模式 適用場景 支持多種觀感標(biāo)準(zhǔn)的用戶界面工具箱。游戲開發(fā)中的多風(fēng)格系列場景，比如道路，房屋，管道等。系統(tǒng)要在三個不同平臺上運(yùn)行，比如windows、linux、android上運(yùn)行，你會怎么設(shè)計(jì)？分別設(shè)計(jì)三套不同的應(yīng)用？通過抽象工廠模式屏蔽掉操作系統(tǒng)對應(yīng)用的影響。三個不同操作系統(tǒng)上的軟件功能、應(yīng)用邏輯、ui都應(yīng)該是非常類似，唯一不同的是調(diào)用不同的工廠方法，由不同的產(chǎn)品類去處理與操作系統(tǒng)交