設(shè)計模式學習總結(jié)

..設(shè)計模式學習總結(jié)引子剛開場學習設(shè)計模式的時候，感到這些模式真的非常抽象。今年下半年以來，隨著我們組工作重點的轉(zhuǎn)移，以及我在小組中角色的變化，我開場有條件提出自己對新系統(tǒng)的設(shè)計想法。在設(shè)計過程中，我發(fā)現(xiàn)了很多設(shè)計模式的用處，也確實應(yīng)用了很多設(shè)計模式，這讓我越來越感到設(shè)計模式的重要性，因此我寫了這十余篇專門介紹設(shè)計模式的文章，作為我的學習筆記。"設(shè)計模式——可復用的面向?qū)ο筌浖母?〔有趣的是，梅宏一再在組會上強調(diào)應(yīng)該譯成重用〕中介紹了一共23種設(shè)計模式，我一共寫了19個設(shè)計模式〔其中三個和在一篇文章中〕，余下四個，考慮到該模式的應(yīng)用圍我就沒有介紹。在寫這些文章時，其中的很多例子都是我在實踐中提煉出來的，當然也有很大一局部是"設(shè)計模式"中的例子。不過，這四個人〔四人團〕生活的年代里現(xiàn)在已經(jīng)很遠了，所以它們的例子也很古老。讓我們更加設(shè)計模式設(shè)計模式是個好東西，它給出了很多設(shè)計中的技巧與思路，對于很多優(yōu)秀的設(shè)計，它加以總結(jié)與提煉。設(shè)計模式并非四人團拍腦瓜想出來的，而是他們搜集了其他人優(yōu)秀的設(shè)計，加以整理出來的，他們不是這些模式的創(chuàng)造者，僅僅是整理者。應(yīng)用設(shè)計模式會給我們帶來很多好處：軟件將變得更加靈活，模塊之間的耦合度將會降低，效率會提升，開銷會減少。更重要的，設(shè)計模式就好似美聲唱法中的花腔，讓你的設(shè)計更加漂亮。總的來說，設(shè)計模式似乎將軟件設(shè)計提升到藝術(shù)的層次。設(shè)計模式已經(jīng)被廣泛的應(yīng)用了，在現(xiàn)在很多的圖形界面框架都使用了MVC模式，大量跌代器模式的應(yīng)用，徹底改變了我們對集合的操作方式。不僅如此，應(yīng)用了設(shè)計模式的設(shè)計，往往被看成為優(yōu)秀的設(shè)計。這是因為，這些設(shè)計模式都是久經(jīng)考驗的。模式不是模型在學習和使用設(shè)計模式的時候，往往出現(xiàn)一個非常嚴重的誤區(qū)，那就是設(shè)計模式必須嚴格地遵守，不能修改。但是設(shè)計模式不是設(shè)計模型，并非一成不變。正相反，設(shè)計模式中最核心的要素并非設(shè)計的構(gòu)造，而是設(shè)計的思想。只有掌握住設(shè)計模式的核心思想，才能正確、靈活的應(yīng)用設(shè)計模式，否那么再怎么使用設(shè)計模式，也不過是生搬硬套。當然，掌握設(shè)計模式的思想，關(guān)鍵是要仔細研究模式的意圖和構(gòu)造。一個模式的意圖，就是使用這個設(shè)計模式的目的，表達了為什么要使用這個模式，也就是需求問題。這個模式的構(gòu)造，就是如何去解決這個問題，是一種手段、一種經(jīng)典的解決方法，這種解決方法只是一種建議。兩個方面結(jié)合起來，明白為什么需要設(shè)計模式，同時明白了如何實現(xiàn)這個模式，就容易抓住模式的本質(zhì)思想。在抓住意圖和構(gòu)造的根底上，實踐也是掌握設(shè)計模式的必要方法。當然，設(shè)計模式必須在某個場景下得到應(yīng)用才有意義，這也是為什么"設(shè)計模式"中提供了大量的例子用來說明模式的應(yīng)用場景，這實際上為讀者提供了一種上下文環(huán)境。學外語不是要強調(diào)"語言環(huán)境〞么，學習設(shè)計模式也是這樣。不要設(shè)計模式看到網(wǎng)上很多人在討論設(shè)計模式，他們確實很有***，滿嘴都是模式的名字，恨不得寫個HelloWorld都要應(yīng)用到設(shè)計模式。設(shè)計模式確實是好東西，但是，中國有句古話叫作物極必反，即便是按照辯證法，事物總要一分為二的看。我們說設(shè)計模式的目的是為了讓軟件更加靈活，重用度更高。但是，某種意義上，設(shè)計模式增加了軟件維護的難度，特別是它增加了對象之間關(guān)聯(lián)的復雜度。我們總說，重用可以提高軟件開發(fā)的效率。如果你是大牛，你自然希望你的設(shè)計可以被反復使用10000年，那就是：當世界消滅的時候，你的設(shè)計依然存在。然而，現(xiàn)實是一個系統(tǒng)的設(shè)計往往在5年之就會被拋棄，這是因為：1，軟件技術(shù)產(chǎn)生了新的變化，使用新的技術(shù)進展的設(shè)計，無論如何都比你的設(shè)計好；2，硬件環(huán)境發(fā)生了很大變化，你的設(shè)計里對開銷或者效率的追求已經(jīng)沒有意義了；3，新的大牛出現(xiàn)了，并且取代了你的位置。應(yīng)用設(shè)計模式會導致設(shè)計周期的加長〔因為更復雜了〕，但是很多工程還在設(shè)計階段就已經(jīng)胎死腹中，再好的設(shè)計也沒有發(fā)揮的余地。當我們向設(shè)計模式頂禮膜拜的時候，我們還必須清醒地看到軟件生產(chǎn)中非技術(shù)層面上的東西往往具有決定性作用。理想固然崇高，但現(xiàn)實總是殘酷的。如何看清理想與現(xiàn)實的界限，恐怕是需要我們在實踐中不斷磨礪而體會出來的。在看完設(shè)計模式后，不妨反問以下自己，這些模式終究能給你帶來什么？Interpreter、Iterator、State模式Interpreter模式：這個模式主要試圖去解釋一種語言。如果你學過形式語言，那么這個模式對你來說是多余的。Iterator模式：這個模式試圖隱藏集合的部表示，又同時可以使用戶依次訪問集合中的元素?，F(xiàn)在STL和Java的跌代器就是應(yīng)用這個模式的結(jié)果。State模式：這個模式的意圖是允許對象在其狀態(tài)改變時修改其行為，好似對象改變了。這個模式的應(yīng)用場景是當對象的行為依賴于對象的狀態(tài)時。為了實現(xiàn)這個模式，我們可以為每個狀態(tài)下的行為實現(xiàn)一個類，當對象的狀態(tài)發(fā)生改變，它調(diào)用不同狀態(tài)對象的實例方法。注意，以前可能需要使用switch或者if語句進展分支轉(zhuǎn)換，現(xiàn)在那么利用多態(tài)機制完成。Flyweight模式這個模式利用共享有效的支持大量的細粒度的對象。比方，編輯軟件中，一篇文章有很多個字符，我們可以對每個字符對象生成一個對象，如果這篇文章有幾M個文字，那么對象的數(shù)量肯定是不能容忍的。使用Flyweight模式，我們將所有的文字對象共享起來，文章中的字符僅僅是指向共享池中的某個對象的索引。在這里要搞清楚一件事情，利用Flyweight模式不會有效地減少信息的數(shù)量〔也就是軟件的空間開銷〕，因為無論是否共享，表達這么多信息所需要的編碼數(shù)量是一定的，所以開銷不會大幅減小。只是，這個模式會減少系統(tǒng)中對象的數(shù)量，因為大量的對象會被共享。在編輯軟件中，字符對象被共享，那么一篇文章中的文字，可以按照段落、格式等等進展結(jié)組，一組文字構(gòu)成一個對象，這樣對象從單個文字變成一組文字，數(shù)量大幅減少。在使用Flyweight模式需要注意的一點，由于對象被共享了，因此這些對象沒有各自的屬性，那么根據(jù)上下文環(huán)境，我們在使用這些對象的時候，必須向它傳遞一些參數(shù)。在編輯軟件中，這些參數(shù)可能就是字體、字號、顏色等等信息。使用Flyweight模式還有一個好處，那就是我們可以在不修改系統(tǒng)的情況下增加享元。mand模式mand模式，將一個請求封裝為一個對象。這樣，你可以向客戶端發(fā)送不同請求的參數(shù)，排隊或記錄請求，同時可以支持不能執(zhí)行的請求。在軟件中，不同的模塊、對象之間經(jīng)常會各種調(diào)用，或者我們稱之為請求。傳統(tǒng)的方法，我們將請現(xiàn)為函數(shù)調(diào)用。這樣做是最簡單的方法，但卻在無形之中增加了模塊之間的耦合度。當請求發(fā)生很大變化的時候，系統(tǒng)將變得很難維護。與此同時，當效勞端〔承受請求的一端〕增加或者刪除一個請求的時候，按照傳統(tǒng)的方法，客戶端〔發(fā)送請求的一端〕也必須重新編譯〔這一點在刪除請求的時候最明顯〕，這樣系統(tǒng)才能正確運行。使用mand模式的一個核心思想就是，效勞端提供一個統(tǒng)一的請求處理接口，客戶端那么通過調(diào)用接口向效勞端發(fā)送請求，這些請求被封裝成對象的形式〔或者其等價形式〕。在"設(shè)計模式"中，"四人團〞并沒有強調(diào)統(tǒng)一接口的事情，它強調(diào)了另一個方面，那就是封裝請求。事實上，封裝一個請求總是要求有一個地方來承受和處理這個請求的，這個地方實際上就是統(tǒng)一請求接口。在"設(shè)計模式"中，請求被封裝成一個mand對象，這個對象保存著請求類型、參數(shù)等信息，效勞端收到這個命令后就會執(zhí)行mand對象中的Execute()函數(shù)，這個函數(shù)具體實現(xiàn)了真正的操作。這種實現(xiàn)方法可以保證增加新的請求而不必重新編譯效勞端。我個人認為，mand模式的另一個形式就是在效勞端實現(xiàn)各種操作，mand對象只是負責指明請求的類型，這樣，當效勞器端發(fā)現(xiàn)請求不正確時，可以忽略該請求。和上一種形式相比，這種形式更加簡潔〔因為可以不真正實現(xiàn)mand對象，在C++中可以使用不定參數(shù)實現(xiàn)〕，但是缺少靈活性。mand模式使得記錄請求成為了可能，我們可以捕獲系統(tǒng)中的請求對象，記錄他們。posite模式posite模式的意圖是"將對象組合成樹形構(gòu)造表示‘整體-局部’的層次構(gòu)造。posite使得用戶對單個對象和組合對象的使用更具有一致性〞。在Word中我們經(jīng)常會將一些圖元進展"組合〞，組合以后的圖形還可以向簡單圖元那樣進展移動、變形等等操作；除此以外，在Word中，我們對于一個字符、一個詞組、一句話、一個段落，甚至是整篇文章的操作是一樣的，我們都可以進展剪切、復制，進展字體與大小的調(diào)整，進展顏色的變換。這些例子都是posite模式的實例，我們將簡單的元素組合成復雜的元素，然后還可以像操作簡單元素那樣操作組合元素。posite模式將子元素組織成樹型，實際上，組織成圖型也沒有問題。用戶總是喜歡組合簡單元素，一方面，用戶可以通過這樣的組合來進展抽象，另一方面，用戶可以通過組合化簡繁瑣的操作。posite模式在各種可視化編輯軟件中應(yīng)用得最為廣泛。另一使用posite的經(jīng)典例子是Java的Swing系統(tǒng)。所有的Swing組件都是繼承自一個叫做Jponent的接口，因此，我們對一個JFrame的操作和對一個utton的操作是一樣的。這同時也使得，JFrame在管理自己的子元素時，它不需要知道他們是一個utton還是一個JPanel，對它來說，這只是一個Jponent。實現(xiàn)posite模式的關(guān)鍵是良好設(shè)計的接口，人們應(yīng)該對可能的元素〔簡單的、組合的〕進展分析，并設(shè)計出通用的操作。盡可能的保證接口操作對所有元素都是有意義的，否那么就應(yīng)該將那些只對局部元素有意義的操作下放到子類中。Proxy模式按照"四人團〞的說法，Proxy模式可以為控制另一個對象而提供一個代理或者占位符。這個模式可以使我們在真正需要的時候創(chuàng)立對象，如果我們不需要這個對象，Proxy模式會為我們提供一個占位符。如果我們有大量這樣消耗很大的對象的時候，我們就可以使用Proxy模式，初始情況下，Proxy模式只會提供占位符而不會真正創(chuàng)立對象，但是對于使用者來說，他看到是真正的對象而不是一個代理。一旦使用者需要獲得或者更改對象屬性的時候，Proxy模式就會創(chuàng)立該對象，在此之后，我們就可以通過代理訪問真正的對象了。在Word里面應(yīng)該是使用了Proxy模式。翻開一篇含圖的很長的文檔時，大局部的圖片都不會被載入，而僅僅是提供占位符，只有當用戶準備觀察這一頁的時候，代理才會真正載入圖片。和Singleton模式一樣，Proxy模式都是保證我們可以按需分配對象，不同的是，Singleton模式還會保證在全局圍使用同一個對象實例，而Proxy那么沒有這個功能。Visitor模式按照"四人團〞的說法，Visitor模式的意圖為：將元素的操作表示成一種構(gòu)造。這樣Visitor模式可以使你在不修改元素構(gòu)造的前提下增加新的操作?？紤]一個鏈表，我們需要一個求得最大元素的操作，這個操作可能是遍歷每個節(jié)點，然后求的最大值。這個時候我們又需要一個為每個元素加1的操作，這個操作還需要遍歷每個節(jié)點，同時將每個元素加1。與之類似，還會有很多其他的針對元素操作，他們的特點都是要遍歷鏈表。這個時候可以使用Visitor模式，結(jié)點類負責依次遍歷，并調(diào)用Visitor類中的函數(shù)，而Visitor類的具體實現(xiàn)那么負責完成功能。這里需要注意的是，Visitor類只能是一個接口，針對不同的操作需要有不同的具體實現(xiàn)，針對不同的具體元素，需要設(shè)計不同的操作。每個元素負責選擇自己應(yīng)該調(diào)用的操作，Visitor子類負責實現(xiàn)具體功能。一個的應(yīng)用是SmallTalk-80的編譯器，在編譯時，編譯器需要建立一棵語法樹。在這個時候，它使用了Visitor模式，針對不同的操作，比方：類型檢查、代碼生成等操作實現(xiàn)不同的Visitor具體類，Visitor類中針對不同的節(jié)點類型提供不同的操作接口，具體的節(jié)點負責選擇調(diào)用哪種接口，這像是一種回調(diào)操作。Observer模式按照"四人團〞的說法，Observer模式的意圖是"定義對象間的一種一對多的依賴關(guān)系，當一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新〞。實際應(yīng)用的例子是，比方建模工具中，假設(shè)干條線形元素附著在一個塊狀元素上，當塊狀元素的大小、位置發(fā)生變化，那些線形元素也需要進展改變，這個時候我們就可以應(yīng)用Observer模式，在塊狀元素和線形元素之間建立一對多的關(guān)系，并利用這一模式進展維護。Observer模式首先構(gòu)造一個Observer類，在這個類中具有一個update函數(shù)。被依賴的對象擁有它，依賴的對象被注冊到Observer中，當被依賴的對象發(fā)生變化的時候，就調(diào)用update函數(shù)更新所有依賴它的對象。更新的方式由update函數(shù)具體實現(xiàn)。還有一個現(xiàn)實中的例子，各個部門之間進展通訊，當一方發(fā)出新的信息時，按照傳統(tǒng)的方法它必須告訴所有其他部門。如果使用Observer模式，那么產(chǎn)生新消息的一方只需要告知Observer，由Observer通知其他方面。TemplateMethod模式TemplateMethod模式的意圖是："定義一個操作中的骨架，而將一些步驟延遲到子類中。這使得子類可以不改變一個算法的構(gòu)造即可以重定義該算法的某些特定步驟。這一模式和Strategy模式似乎和相似，但是他們的關(guān)注點不同。策略模式主要用于算法的替換，但是模板方法模式主要用于算法中特定步驟地替換。一個應(yīng)用模板方法模式的例子是數(shù)據(jù)庫操作。對于數(shù)據(jù)庫操作可以有很多中，比方查詢、更新。查詢又可以分為連接數(shù)據(jù)庫、發(fā)送請求命令、解析結(jié)果等等步驟。對于不同的數(shù)據(jù)庫，比方Oracle和SQL2000，它們連接數(shù)據(jù)庫、命令格式可能有所不同，但是就查詢和更新著兩個操作來說它們的步驟是一樣的。這個時候，我們可以應(yīng)用模板方法模式，為查詢、更新操作建立一個抽象的算法，具體的步驟交給子類來實現(xiàn)。如果對于策略模式，我們替換的將是查詢和更新著兩個操作。但是，將TemplateMethod模式和Strategy模式進展類比是危險的，這兩個模式有著很多重要的不同，但這些不同卻又是十分的細微，只能意會不能言傳。FactoryMethod模式這一模式的意圖是："定義一個用于創(chuàng)立對象的接口，讓子類決定實例化哪一個類。FactoryMethod是一個類的實例化延遲到其子類。〞這一模式的關(guān)鍵是掌握"何時應(yīng)用這一模式〞，事實上我覺得這也是所有設(shè)計模式的關(guān)鍵。一個的應(yīng)用就是MFC中關(guān)于Document和Frame之間的關(guān)系。通常在生成一個多文檔程序時，VC會為你創(chuàng)立一個Frame類和Document類，你的Frame類可以用來相應(yīng)OnFileNew消息，然后創(chuàng)立一個Document對象。但是對于Windows的消息系統(tǒng)來說，它并不知道用戶程序中創(chuàng)立的Document類有什么特性，對于它來說，它所看到是CFrame對象和CDocument對象。FactoryMethod模式可以保證其他對象不需要知道具體對象的類型而管理這些對象，這一模式通常用于制定框架。這一模式和AbstractFactory模式很相像，事實上AbstractFactory模式可以由一系列FactoryMethod模式實現(xiàn)。Strategy模式Strategy模式的目的就是"定義一系列的算法，把他們一個個封裝起來，并且使他們可以互相替換。〞如何理解這一模式，首先看下面這個場景：一組數(shù)據(jù)進展排序，我們可以選擇很多中排序算法，這個時候我們定義一個排序策略，然后每個排序算法實現(xiàn)一個具體策略，這樣用戶就可以在幾個不同的排序算法中隨意選擇和替換了。當然，上面的例子中使用策略模式似乎多此一舉，那么假設(shè)游戲中的敵人的AI，根據(jù)玩家的設(shè)定可以有不同的級別。在這種情況下，使用策略模式就是十分必要的了。Bridge模式按照"四人團〞的說法，Bridge模式的意圖是：將抽象局部與他的實現(xiàn)局部別離，使得他們可以獨立的變化。你一定會感到一陣眩暈，不明白這是什么意思。首先應(yīng)該說明的是"抽象〞與"實現(xiàn)〞的含義。在剛剛的那句話中，"抽象〞與"實現(xiàn)〞并不是我們在描述類構(gòu)造時所說的"接口〞與它的"實現(xiàn)〞，或者在Java中抽象類與他的實現(xiàn)。在這里，"抽象〞與"實現(xiàn)〞只得是某種工作，"抽象〞是說如何完成這項工作，"實現(xiàn)〞是說"抽象〞中所用的步驟的實現(xiàn)。一個例子可以很好的說明"抽象〞與"實現(xiàn)〞的關(guān)系。我們編寫一個游戲，這個游戲有兩個版本，DX版本和OpenGL版本。我們?nèi)绾尉帉戇@兩個版本呢？一種方法是我們在這兩個引擎上開發(fā)兩套獨立的游戲，但這顯然不是最好的方法。另一個選擇是我們將游戲的"抽象〞局部與"實現(xiàn)〞局部別離，開發(fā)一套"抽象〞局部，開發(fā)兩套"實現(xiàn)〞局部。那么什么是游戲的"抽象〞局部？很顯然就是游戲的繪圖〔也許用更專業(yè)詞匯的應(yīng)該是：渲染〕過程，例如我們?nèi)绾武秩居螒虻娜宋铮@個人物可能是由很多個多邊形組合而成的，我們按照一定的方法渲染之后，就可以畫出一個人物來。這一局部就可以看作是"抽象〞。那么另一方面就是"實現(xiàn)〞局部，在上面的例子中，"實現(xiàn)〞局部就是如何繪制根底的線條、填充顏色，甚至是初始化屏幕等等。這些"實現(xiàn)〞和具體的引擎密切相關(guān)。為什么說我們可以將"抽象〞和"實現(xiàn)〞別離，使得他們可以各自變化呢？假設(shè)現(xiàn)在要開發(fā)新的游戲，或者這個游戲升級了，在其中出現(xiàn)了新的人物，那么"抽象〞局部就發(fā)生了變化，但是具體"實現(xiàn)〞沒有變化，因此這個游戲還可以繼續(xù)在你的計算機上運行。另一方面，如果游戲需要進展移植，目標平臺的圖形系統(tǒng)發(fā)生了變化，你可能需要使用新的繪圖引擎，這個時候，你只需要利用新的引擎實現(xiàn)根本的"實現(xiàn)〞操作，原始的程序就可以在新的平臺上運行〔略去重新編譯的問題〕。Facade模式Facade模式的目的就是給子系統(tǒng)提供一個統(tǒng)一的接口?，F(xiàn)在的軟件都是按照模塊進展劃分，對不同的模塊分別進展編程。但是在用戶開來，不同的模塊應(yīng)該具有統(tǒng)一的接口，換句話說，我們應(yīng)該可以通過統(tǒng)一的接口訪問系統(tǒng)中的所有功能。有一個很典型的例子就是編譯系統(tǒng)。通常我們將編譯系統(tǒng)分解為：pile和Link兩個步驟。一個pile又可以分解為詞法分析、語法分析、語義分析、中間代碼生成等等步驟。對于用戶來講，我們不可能將這些模塊分別提供應(yīng)他們，讓他們依次調(diào)用。相反的，我們應(yīng)該提供一個統(tǒng)一的接口，使得用戶可以方便的使用各個功能，例如IDE。Facade模式在強調(diào)模塊化開發(fā)的同時也強調(diào)模塊的統(tǒng)一，統(tǒng)一的接口也有利于子系統(tǒng)中模塊部的變化。對于開發(fā)大型系統(tǒng)來說，F(xiàn)acade模式是不可缺少的。Decorator模式按照"四人團〞的說法，Decorator模式的意圖是：動態(tài)的給一個對象添加一些額外的職責。值得注意的是，這個對象不知道他增加的是什么職責。這個模式的一個典型應(yīng)用實例是：Java的流。一個文件流〔Java.IO.File〕用于讀寫文件，如果你想使用文件緩沖，你可在為File添加一個BufferedInputStream或者BufferedOutputStream外觀，這樣這個文件流就具有了緩沖。再如一個Reader類，你可以給他增加緩沖BufferedReader，然后你還可以給這個緩沖流增加一些格式化讀取的能力。Decorator模式可以動態(tài)的增加對象的額外的職責，這也有利于將額外的功能分別實現(xiàn)，使得用戶可以自由組合。Adapter模式有一天你在網(wǎng)上找到一個庫，你打算把它應(yīng)用到你的程序當中去，但是你發(fā)現(xiàn)這個庫的函數(shù)不符合你的風格，你會怎么辦？一個很簡單的方法就是使用Adapter模式。Adapter模式的目的就是將一個類的接口轉(zhuǎn)換為用戶希望的接口，使得由于接口不兼容而不能一起工作的各個類可以一起工作。例如在一個軟件里面可能使用了以前一個版本的類庫。不幸的是這個類庫的效率極高卻和現(xiàn)在的接口不兼容，為了繼續(xù)復用這個類庫我們就可以使用Adapter模式，在原來的類庫和現(xiàn)在的接口中間實現(xiàn)一個適配器，使得我們可以用現(xiàn)在的構(gòu)造調(diào)用以前的類庫。例如一個繪圖程序〔這種事情總是出現(xiàn)在這類程序中〕，以前的類庫中提供繪制直線的方法DrawLine，但是新的接口要求繪圖系統(tǒng)還要提供繪制矩形、折線形的方法，為了復用這個類庫，我們實現(xiàn)一個Adapter類，這個類中利用以前的繪圖系統(tǒng)提供的方法實現(xiàn)了新的接口功能。Singleton模式這可能是最簡單的一個模式了，但是他的應(yīng)用卻是最多的。這個模式的目的就是保證一個對象只有一個實例，并且提供一個全局的訪問點。那么這個模式的怎么實現(xiàn)呢？很簡單，你首先必須為這個類設(shè)置一個指針〔Java中是引用〕，然后提供一個方法用來獲得這個類的實例。在這個方法中首先判斷這個指針是否為空，如果是，那么創(chuàng)立一個實例，否那么直接返回這個指針。雖然我們可以提供一個全局訪問點，但實際上這個模式也可以應(yīng)用到局部。應(yīng)用這個模式一個好處就是可以"按需分配〞，同時也封裝了對象的獲取過程。不管如何，我覺得應(yīng)該盡可能的應(yīng)用這個模式，雖然這會讓你感到很煩……這個模式在實現(xiàn)過程中可以進展變化，例如在Instance()方法上添加參數(shù)BooleanbAlloc，用于指定當實例不存在的時候是否進展創(chuàng)立。這樣做是考慮到，有些時候我們獲得實例的目的不是為了修改，而是為了讀取。這個時候，返回一個空實例和返回一個沒有被修改正的實例在邏輯上是一樣的。例如，這個對象是一個數(shù)組時，一個"空數(shù)組〞和一個"空白的數(shù)組〞是一樣的。Builder模式按照"四人團〞的說法，Builder模式的目的是：將一個復雜對象的構(gòu)建與他的表示別離，使得同樣的構(gòu)建過程可以創(chuàng)立不同的表示。一個典型的例子是：文件的格式轉(zhuǎn)換。假設(shè)一個RTF文件，我們可以將它轉(zhuǎn)換成不同的格式，比方TXT、DOC、PDF等等。在這些目標格式的文件中，有些文件格式中保存文本字體〔比方DOC〕，有些可能不保存〔比方TXT〕。當我們開場轉(zhuǎn)換過程時，按照RTF文件自己的格式進