第一篇：Java23種設(shè)計(jì)模式6大原則總結(jié)

設(shè)計(jì)模式概念：一套被反復(fù)使用、多數(shù)人知曉、經(jīng)過(guò)分類(lèi)編目的優(yōu)秀代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。設(shè)計(jì)模式要素：模式名稱、問(wèn)題、舉例、末態(tài)環(huán)境、推理、其他有關(guān)模式、已知的應(yīng)用。設(shè)計(jì)模式分類(lèi)：創(chuàng)建型、結(jié)構(gòu)型、行為型。

創(chuàng)建型模式功能：1.統(tǒng)所使用的具體類(lèi)的信息封裝起來(lái)；

2.類(lèi)的實(shí)例是如何被創(chuàng)建和組織的。

創(chuàng)建型模式作用：1.封裝創(chuàng)建邏輯，不僅僅是new一個(gè)對(duì)象那么簡(jiǎn)單。

2.封裝創(chuàng)建邏輯變化，客戶代碼盡量不修改，或盡量少修改。

常見(jiàn)的創(chuàng)建型模式：?jiǎn)卫Ｊ健⒐S方法模式、抽象工廠模式、建造者模式、原型模式。常見(jiàn)的結(jié)構(gòu)型模式：代理模式、裝飾模式、適配器模式、組合模式、橋梁模式、外觀模式、享元模式。

常見(jiàn)行為型模式：模板方法模式、命令模式、責(zé)任鏈模式、策略模式、迭代器模式、中介者模式、觀察者模式、備忘錄模式、訪問(wèn)者模式、狀態(tài)模式、解釋器模式。

單一職責(zé)原則：一個(gè)類(lèi)應(yīng)該只有一個(gè)職責(zé)。

優(yōu)點(diǎn)：降低類(lèi)的復(fù)雜性；提高類(lèi)的可讀性；提高代碼的可維護(hù)性和復(fù)用性；降低因變更引起的風(fēng)險(xiǎn)。

里氏替換原則：

優(yōu)點(diǎn)：代碼共享，減少創(chuàng)建類(lèi)的工作量，每個(gè)子類(lèi)都擁有父類(lèi)的方法和屬性；提高代碼的可重用性；提高代碼的可擴(kuò)展性；提高產(chǎn)品或項(xiàng)目的開(kāi)放性。

缺點(diǎn)：1.繼承是入侵式的。只要繼承，就必須擁有父類(lèi)所有屬性和方法。

2.降低代碼的靈活性。子類(lèi)必須擁有父類(lèi)的屬性和方法，使子類(lèi)收到限制。

3.增強(qiáng)了耦合性。當(dāng)父類(lèi)的常量、變量和方法修改時(shí)，必須考慮子類(lèi)的修改，這種修改可能造成大片的代碼需要重構(gòu)。

依賴倒置原則：高層模塊不應(yīng)該依賴低層模塊，兩者都依賴其抽象；抽象不依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴于抽象。

在Java中的表現(xiàn)：模塊間的依賴通過(guò)抽象發(fā)生，實(shí)現(xiàn)類(lèi)之間不發(fā)生直接的依賴關(guān)系，其依賴關(guān)系是通過(guò)接口或抽象類(lèi)產(chǎn)生的；接口或抽象類(lèi)不依賴于是實(shí)現(xiàn)類(lèi)；實(shí)現(xiàn)類(lèi)依賴于接口或抽象類(lèi)。

接口隔離原則：1.一個(gè)類(lèi)對(duì)另外一個(gè)類(lèi)的依賴性應(yīng)當(dāng)是建立在最小的接口上的 2.一個(gè)接口代表一個(gè)角色，不應(yīng)當(dāng)將不同的角色交給一個(gè)接口。3.不應(yīng)該強(qiáng)迫客戶使用它們的不同方法。

如圖所示的電子商務(wù)系統(tǒng)在三個(gè)地方會(huì)使用到訂單類(lèi)：一個(gè)是門(mén)戶，只能有查詢方法；一個(gè)是外部系統(tǒng)，有添加訂單的方法；一個(gè)是管理后臺(tái)，添加、刪除、修改、查詢都要用到?！霸印痹趯?shí)踐中的衡量規(guī)則：

1.一個(gè)接口只對(duì)一個(gè)子模塊或者業(yè)務(wù)邏輯進(jìn)行分類(lèi)。2.只保留接口中業(yè)務(wù)邏輯需要的public方法。

3.盡量修改污染了的接口，若修改的風(fēng)險(xiǎn)較大，則可采用適配器模式進(jìn)行轉(zhuǎn)化處理。4.接口設(shè)計(jì)應(yīng)因項(xiàng)目而異，因環(huán)境而異，不能照搬教條。迪米特法則：（表述）只與你直接的朋友們通信；不要跟“陌生人”說(shuō)話；每一個(gè)軟件單位對(duì)其他的單位都只有最少的了解，這些了解僅局限于那些與本單位密切相關(guān)的軟件單位。

對(duì)迪米特法則進(jìn)行模式設(shè)計(jì)有兩個(gè)：外觀模式、中介者模式。開(kāi)閉原則：一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。

重要性體現(xiàn)：提高復(fù)用性；提高維護(hù)性；提高靈活性；易于測(cè)試 單例模式：?jiǎn)卫Ｊ酱_保某一個(gè)類(lèi)只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例單例模式。

優(yōu)點(diǎn)：1.在內(nèi)存中只有一個(gè)實(shí)例，減少了內(nèi)存的開(kāi)支。2.只生成一個(gè)實(shí)例，減少了系統(tǒng)的性能開(kāi)銷(xiāo)。3.避免對(duì)資源的多重占用。

4.可以在系統(tǒng)設(shè)置全局的訪問(wèn)點(diǎn)，優(yōu)化和共享資源訪問(wèn)。缺點(diǎn)：1.無(wú)法創(chuàng)建子類(lèi)，擴(kuò)展困難，若要擴(kuò)展，除修改代碼基本上沒(méi)有第二種途徑可以實(shí)現(xiàn)。2.對(duì)測(cè)試不利。3.與單一職責(zé)原則有沖突。餓漢式單例類(lèi)與懶漢式單例類(lèi)之間的區(qū)別：

1.餓漢式單例類(lèi)在被加載時(shí)實(shí)例化，而懶漢式單例類(lèi)在第一次引用時(shí)實(shí)例化。2.從資源利用效率上說(shuō)，餓漢式單例類(lèi)要差一點(diǎn)，但從速度和反應(yīng)時(shí)間的角度來(lái)講，餓漢式單例類(lèi)則比懶漢式單例類(lèi)稍好些。

3.餓漢式單例類(lèi)可以在Java中實(shí)現(xiàn)，但不易在C++中實(shí)現(xiàn)。單例模式的使用場(chǎng)景：

1.要求生成唯一的序列號(hào)環(huán)境。

2.在整個(gè)項(xiàng)目中需要一個(gè)共享訪問(wèn)點(diǎn)或共享數(shù)據(jù)。3.創(chuàng)建一個(gè)對(duì)象需要消耗的資源過(guò)多。4.需要定義大量的靜態(tài)方法的環(huán)境。使用單例模式的注意事項(xiàng)：

1.在使用任何EJB、RMI和JINI的分布式系統(tǒng)中，應(yīng)當(dāng)避免使用有狀態(tài)的單例類(lèi)。2.同一個(gè)JVM中會(huì)有多個(gè)類(lèi)加載器，當(dāng)兩個(gè)類(lèi)加載器同時(shí)加載一個(gè)類(lèi)時(shí)，會(huì)出現(xiàn)兩個(gè)實(shí)例，此時(shí)也應(yīng)當(dāng)盡量避免使用有狀態(tài)的單例類(lèi)。

工廠方法模式：定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類(lèi)決定實(shí)例化那個(gè)類(lèi)。

優(yōu)點(diǎn)：良好的封裝性，代碼結(jié)構(gòu)清晰；優(yōu)秀的可擴(kuò)展性；屏蔽產(chǎn)品類(lèi)；典型的解耦框架。使用場(chǎng)景：1.工廠方法模式是new一個(gè)對(duì)象的替代品，故在所有需要生成對(duì)象的地方都可以使用，但是需要慎重考慮是否需要增加一個(gè)工廠類(lèi)進(jìn)行管理，增加代碼的復(fù)雜度。

2．需要靈活的、可擴(kuò)展的框架時(shí)。3.可以用在異構(gòu)項(xiàng)目中。

4.可以使用在測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的框架下。

抽象工廠模式：為創(chuàng)建一組相關(guān)或相互依賴的對(duì)象提供一個(gè)接口，且無(wú)需指定它們的具體類(lèi)。優(yōu)點(diǎn)： 1.產(chǎn)品族內(nèi)的約束為非公開(kāi)狀態(tài)，在不同的工廠中，各種產(chǎn)品可能具有不同的相互依賴關(guān)系，這些依賴關(guān)系由工廠封裝在其內(nèi)部，對(duì)于工廠的使用者是不可見(jiàn)的。

2.生產(chǎn)線的擴(kuò)展非常容易，如果要針對(duì)同一產(chǎn)品族建立新的生產(chǎn)線，只需要實(shí)現(xiàn)產(chǎn)品族中的所有產(chǎn)品接口并建立新的工廠類(lèi)即可。

缺點(diǎn)： 產(chǎn)品族本身的擴(kuò)展非常困難，如果需要在產(chǎn)品族中增加一個(gè)新的產(chǎn)品類(lèi)型，則需要修改多個(gè)接口，并且會(huì)影響已有的工廠類(lèi)。

使用場(chǎng)景：當(dāng)一個(gè)對(duì)象族（或是一組沒(méi)有任何關(guān)系的對(duì)象）都有相同的約束。

建造者將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。優(yōu)點(diǎn)：1.封裝性，可以使客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)。2.建造者獨(dú)立，容易擴(kuò)

3.便于控制細(xì)節(jié)風(fēng)險(xiǎn)。

使用場(chǎng)景：1.相同的方法，不同的執(zhí)行順序，產(chǎn)生不同的結(jié)果。2.多個(gè)部件或零件，都可以裝配到一個(gè)對(duì)象中，但是產(chǎn)生的運(yùn)行結(jié)果又不相同時(shí)。3.產(chǎn)品類(lèi)非常復(fù)雜，或者產(chǎn)品類(lèi)中的方法調(diào)用順序不同產(chǎn)生了不同的效能。4.在對(duì)象創(chuàng)建過(guò)程中會(huì)使用到系統(tǒng)的一些其他對(duì)象，這些對(duì)象在產(chǎn)品對(duì)象的創(chuàng)建過(guò)程中不易得到時(shí)。原型模式：用原型實(shí)例制定創(chuàng)建對(duì)象的種類(lèi)，并且通過(guò)復(fù)制這些原型創(chuàng)建新的對(duì)象。優(yōu)點(diǎn)：性能優(yōu)良；逃避構(gòu)造函數(shù)的約束。

使用場(chǎng)景：資源優(yōu)化場(chǎng)景；性能和安全要求場(chǎng)景；一個(gè)對(duì)象多個(gè)修改者的場(chǎng)景。結(jié)構(gòu)型模式：為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn)。

種類(lèi)：遠(yuǎn)程代理、虛擬代理、保護(hù)代理、緩存代理、同步代理、智能引用代理

優(yōu)點(diǎn)：1.職責(zé)清晰：真實(shí)的角色實(shí)現(xiàn)實(shí)際的業(yè)務(wù)邏輯，不用關(guān)心其他非本職的事務(wù)，通過(guò)后期的代理完成附加的事務(wù)，附帶的結(jié)果就是編程簡(jiǎn)潔清晰。

2.高擴(kuò)展性：具體主題角色隨需求不同可能有很多種，但只要實(shí)現(xiàn)了接口，代理類(lèi)就完全可以在不做任何修改的情況下代理各種真實(shí)主題角色。

3.智能化：代理類(lèi)可以在運(yùn)行時(shí)才確定要去代理的真實(shí)主題，這是一種強(qiáng)大的功能。使用場(chǎng)景：代理模式的應(yīng)用非常廣泛，大到一個(gè)系統(tǒng)框架、企業(yè)平臺(tái)，小到事務(wù)處理、代碼片段，隨處可見(jiàn)代理模式的使用，例如，JavaRMI的遠(yuǎn)程調(diào)用和AOP。

裝飾模式：動(dòng)態(tài)的給一個(gè)對(duì)象添加一些額外的職責(zé)。

優(yōu)點(diǎn)：裝飾類(lèi)和被裝飾類(lèi)都可以獨(dú)立發(fā)展，而不會(huì)相互耦合；裝飾模式是繼承關(guān)系的一個(gè)替代方案；裝飾模式可以動(dòng)態(tài)地?cái)U(kuò)展一個(gè)實(shí)現(xiàn)類(lèi)的功能。

使用場(chǎng)景：1.需要擴(kuò)展一個(gè)類(lèi)的功能，或給一個(gè)類(lèi)增加附加功能。

2.需要?jiǎng)討B(tài)地給一個(gè)對(duì)象增加功能，這些功能可以再動(dòng)態(tài)地撤銷(xiāo)。3.需要為一批類(lèi)進(jìn)行改裝或加裝功能。適配器模式：將一個(gè)類(lèi)的接口變換成客戶端所期待的的另一種接口，從而使原本因接口不匹配而無(wú)法在一起工作的兩個(gè)類(lèi)能夠在一起工作。

優(yōu)點(diǎn)：可以讓兩個(gè)沒(méi)有任何關(guān)系的類(lèi)在一起運(yùn)行；增加了類(lèi)的透明度；提高類(lèi)的復(fù)用度；增強(qiáng)代碼的靈活性。

使用場(chǎng)景：修改一個(gè)已經(jīng)投產(chǎn)中的系統(tǒng)時(shí)，需要對(duì)系統(tǒng)進(jìn)行擴(kuò)展。此時(shí)使用一個(gè)已有類(lèi)，但這個(gè)類(lèi)不符合系統(tǒng)中的接口，這是使用適配器模式是最合適的，它可以將不符合系統(tǒng)接口的類(lèi)進(jìn)行轉(zhuǎn)換，轉(zhuǎn)換成符合系統(tǒng)接口的、可以使用的類(lèi)。

組合模式：將組合成樹(shù)形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)，使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。

優(yōu)點(diǎn)：高層模塊調(diào)用簡(jiǎn)單；節(jié)點(diǎn)自由增加。

缺點(diǎn)：不易控制樹(shù)枝構(gòu)件的類(lèi)型；不易使用繼承的方法來(lái)增加新的行為。

使用場(chǎng)景：1.需要描述對(duì)象的部分和整體的等級(jí)結(jié)構(gòu)，如樹(shù)形菜單、文件和文件夾管理。2.需要客戶端忽略個(gè)體構(gòu)件和組合構(gòu)件的區(qū)別，平等對(duì)待所有的構(gòu)件。橋梁模式：將抽象和現(xiàn)實(shí)解耦，使得兩者可以獨(dú)立地變化。優(yōu)點(diǎn)：1.抽象和現(xiàn)實(shí)的分離是橋梁模式的主要特點(diǎn)，是為了解決繼承的缺點(diǎn)而提出的設(shè)計(jì)模式。在該模式下，實(shí)現(xiàn)可以不受抽象的約束，不用綁定在一個(gè)固定的抽象層次上。2.實(shí)現(xiàn)對(duì)客戶的透明，客戶端不用關(guān)心細(xì)節(jié)的實(shí)現(xiàn)，它已經(jīng)由抽象層通過(guò)聚合關(guān)系完成了封裝。使用場(chǎng)合：1.如果一個(gè)系統(tǒng)需要在構(gòu)件的抽象化角色和具體角色之間增加更多的靈活性，避免在兩個(gè)層次之間建立靜態(tài)的聯(lián)系。

2.設(shè)計(jì)要求實(shí)現(xiàn)化角色的任何改變不應(yīng)當(dāng)影響客戶端，或者說(shuō)實(shí)現(xiàn)化及角色的改變對(duì)客戶端是完全透明的。

3.一個(gè)構(gòu)件有多于一個(gè)抽象化角色和實(shí)現(xiàn)化角色，系統(tǒng)需要它們之間進(jìn)行動(dòng)態(tài)耦合。4.不希望或不適合使用繼承的場(chǎng)合。

外觀模式：要求一個(gè)子系統(tǒng)的外部與其內(nèi)部的通信必須通過(guò)一個(gè)統(tǒng)一的對(duì)象進(jìn)行。

優(yōu)點(diǎn)：1.減少系統(tǒng)的相互依賴，所有的依賴都是對(duì)Fa?ade對(duì)象的依賴，與子系統(tǒng)無(wú)關(guān)。

2．提高靈活性，不管子系統(tǒng)系統(tǒng)內(nèi)部如何變化，只要不影響Fa?ade對(duì)象，任何活動(dòng)都是自由的。

3.提高安全性，F(xiàn)a?ade中未提供的方法，外界就無(wú)法訪問(wèn)，提高系統(tǒng)的安全性。使用場(chǎng)景：1.為一個(gè)復(fù)雜的模塊或子系統(tǒng)提供一個(gè)供外界訪問(wèn)的接口。

2.子系統(tǒng)相對(duì)獨(dú)立，外界子系統(tǒng)的訪問(wèn)只要黑箱操作即可。3.預(yù)防風(fēng)險(xiǎn)擴(kuò)散，使用Fa?ade進(jìn)行訪問(wèn)操作控制。

享元模式：使用共享對(duì)象可有效地支持大量的細(xì)粒度的對(duì)象。

優(yōu)點(diǎn)：大幅減少內(nèi)存中對(duì)象的數(shù)量，降低程序內(nèi)存的占用，提高性能。缺點(diǎn)：1.增加了系統(tǒng)的復(fù)雜性，需要分出外部狀態(tài)和內(nèi)部狀態(tài)，而且內(nèi)部狀態(tài)具有固化特性，不應(yīng)該隨外部狀態(tài)改變而改變，這使得程序的邏輯復(fù)雜化。

2.將享元對(duì)象的狀態(tài)外部化，而讀取外部狀態(tài)使得運(yùn)行時(shí)間變長(zhǎng)。使用場(chǎng)景：1.系統(tǒng)中有大量的相似對(duì)象，這些對(duì)象耗費(fèi)大量的內(nèi)存。

2．細(xì)粒度的對(duì)象都具備較接近的外部狀態(tài)，而且內(nèi)部狀態(tài)與環(huán)境無(wú)關(guān)，即對(duì)象沒(méi)有特定身份。

3.需要緩沖池的場(chǎng)景。

模板方法模式：定義一個(gè)操作中的算法的框架，而將一些步驟延遲到子類(lèi)中。使得子類(lèi)可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。

優(yōu)點(diǎn)：封裝不變的部分，擴(kuò)展可變的部分；提取公共部分代碼，便于維護(hù)；行為由父類(lèi)控制，子類(lèi)實(shí)現(xiàn)。

應(yīng)用場(chǎng)景：1.多個(gè)子類(lèi)有公共方法，并且邏輯基本相同。

2.可以把重要的、復(fù)雜的、核心算法設(shè)計(jì)為模板方法，周邊的相關(guān)細(xì)節(jié)功能則由各個(gè)子類(lèi)實(shí)現(xiàn)。

3.重構(gòu)時(shí)，模板方法模式是一個(gè)經(jīng)常使用的模式，將相同的代碼抽取到父類(lèi)中。命令模式：將一個(gè)請(qǐng)求封裝成一個(gè)對(duì)象，從而讓你使用不同的請(qǐng)求把客戶端參數(shù)化，對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，可以提供命令的撤銷(xiāo)和恢復(fù)功能。

優(yōu)點(diǎn)：類(lèi)間解耦；可擴(kuò)展性；命令模式結(jié)合其他模式會(huì)更優(yōu)秀。

缺點(diǎn)：可能會(huì)導(dǎo)致系統(tǒng)中出現(xiàn)過(guò)多的具體命令類(lèi)，因此需要在項(xiàng)目中慎重考慮使用。應(yīng)用場(chǎng)景：1.使用命令模式作為“回調(diào)”在面向?qū)ο笙到y(tǒng)中的替代；

2.需要在不同的時(shí)間指令請(qǐng)求、將請(qǐng)求排隊(duì)； 3.系統(tǒng)需要支持的撤銷(xiāo)（undo）；

4.需要將系統(tǒng)中所有的數(shù)據(jù)更新操作保存到日志里，以便在系統(tǒng)崩潰時(shí)，可以根據(jù)日志讀回所有的數(shù)據(jù)更新命令，重新調(diào)用execute（）方法一條一條執(zhí)行這些命令，從而恢復(fù)系統(tǒng)在崩潰前所做的數(shù)據(jù)更新； 5.一個(gè)系統(tǒng)需要支持交易（transaction）。

責(zé)任鏈模式：使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求，從而避免請(qǐng)求的發(fā)送者和接受者之間的耦合關(guān)系。將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞該請(qǐng)求，知道有對(duì)象處理它為止。

優(yōu)點(diǎn)：責(zé)任鏈模式將請(qǐng)求和處理分開(kāi)，請(qǐng)求者不知道是誰(shuí)處理的，處理者可以不用知道請(qǐng)求的全貌；提高系統(tǒng)的靈活性。

缺點(diǎn)：1.降低程序的性能，每個(gè)請(qǐng)求都是從鏈頭遍歷到鏈尾，當(dāng)鏈比較長(zhǎng)時(shí)，性能大幅下降。2.不易于調(diào)試，由于采用了類(lèi)似遞歸的方式，調(diào)試的時(shí)候邏輯比較復(fù)雜。

應(yīng)用場(chǎng)景：一個(gè)請(qǐng)求需要一系列的處理工作；業(yè)務(wù)流的處理，例如，文件審批；對(duì)系統(tǒng)進(jìn)行補(bǔ)充擴(kuò)展。策略模式：定義一組算法，將每個(gè)算法都封裝起來(lái)，并且使他們之間可以互換。

優(yōu)點(diǎn)：提供了管理相關(guān)算法族的辦法；提供了可以替換繼承關(guān)系的方法；可以避免使用多重條件轉(zhuǎn)換語(yǔ)句。

缺點(diǎn)：客戶端必須知道所有的策略類(lèi)，并自行決定使用哪一個(gè)策略類(lèi)；策略模式造成很多的策略類(lèi)。

應(yīng)用場(chǎng)景：多個(gè)類(lèi)只是在算法或行為上稍有不同的場(chǎng)景；算法需要自由切換的場(chǎng)景；需要屏蔽算法規(guī)則的場(chǎng)景。

迭代器模式：提供一種方法訪問(wèn)一個(gè)容器對(duì)象中各個(gè)元素，又不需要暴露該對(duì)象的內(nèi)部細(xì)節(jié)。優(yōu)點(diǎn)：1.迭代器模式簡(jiǎn)化了訪問(wèn)容器元素的操作，具備一個(gè)統(tǒng)一的遍歷接口。2.封裝遍歷算法，使算法獨(dú)立于聚集角色。

缺點(diǎn)：1.迭代器模式給使用者一個(gè)序列化的錯(cuò)覺(jué)，從而產(chǎn)生錯(cuò)覺(jué)。2.迭代器的元素都是Object類(lèi)型，沒(méi)有類(lèi)型特征。

中介者模式：用一個(gè)中介對(duì)象封裝一系列對(duì)象（同事）的交互，中介者使對(duì)象不需要顯式地相互作用，從而使其耦合松散，而且可以獨(dú)立地改變他們之間的交互。

優(yōu)點(diǎn)：1.減少類(lèi)間的依賴，將原有的一對(duì)多的依賴變成一對(duì)一的依賴，使得對(duì)象之間的關(guān)系更以維護(hù)和理解。

2.避免同事對(duì)象之間過(guò)度耦合，同事類(lèi)只依賴于中介者，使同事類(lèi)更易被復(fù)用，中介類(lèi)和同事類(lèi)可以相互獨(dú)立地演化。

3.中介者模式將對(duì)象的行為和協(xié)作抽象化，將對(duì)象在小尺度的行為上與其他對(duì)象的相互作用分開(kāi)處理。

缺點(diǎn)：1.中介者模式降低了同事對(duì)象的復(fù)雜性，但增加了中介者類(lèi)的復(fù)雜性。

2.中介者類(lèi)經(jīng)常充滿了各個(gè)具體同事類(lèi)的關(guān)系協(xié)調(diào)代碼，這種代碼是不能復(fù)用的。注意事項(xiàng)：不應(yīng)當(dāng)在責(zé)任劃分混亂時(shí)使用；不應(yīng)當(dāng)對(duì)數(shù)據(jù)類(lèi)和方法類(lèi)使用；正確理解封裝。觀察者模式：定義對(duì)象間一種一對(duì)多的依賴關(guān)系，使得每當(dāng)一個(gè)對(duì)象改變狀態(tài)，則所有依賴于它的對(duì)象都會(huì)得到通知并被自動(dòng)更新。

優(yōu)點(diǎn)：觀察者和被觀察者之間是抽象耦合；支持廣播通信。缺點(diǎn)：1.如果一個(gè)主題有多個(gè)直接或者間接的觀察者，則通知所有的觀察者會(huì)花費(fèi)很多時(shí)間，且開(kāi)發(fā)和調(diào)試都比較復(fù)雜。

2.如果在主題之間有循環(huán)依賴，被觀察者會(huì)觸發(fā)他們間進(jìn)行循環(huán)調(diào)用，導(dǎo)致系統(tǒng)崩潰。3.如果對(duì)觀察者的通知是通過(guò)另外線程進(jìn)行異步投遞，系統(tǒng)必須保證投遞的順利執(zhí)行。4．雖然觀察者模式可以隨時(shí)使觀察者知道所觀察的對(duì)象發(fā)生了變化，但是觀察者模式?jīng)]有提供相應(yīng)的機(jī)制使觀察者知道所觀察的對(duì)象是如何發(fā)生變化。

應(yīng)用場(chǎng)景：關(guān)聯(lián)行為場(chǎng)景；事件多級(jí)觸發(fā)場(chǎng)景；跨系統(tǒng)的消息交換場(chǎng)景。注意事項(xiàng)：廣播鏈的問(wèn)題；異步處理的問(wèn)題。

備忘錄模式：在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣，以后就可以將該對(duì)象恢復(fù)到原先保存的狀態(tài)。

應(yīng)用場(chǎng)景：需要保存和恢復(fù)數(shù)據(jù)的相關(guān)場(chǎng)景狀態(tài)；提供一個(gè)可回滾的操作；需要監(jiān)控副本的場(chǎng)景；數(shù)據(jù)庫(kù)連接的事務(wù)管理使用的就是備忘錄模式。

注意事項(xiàng)：1.備忘錄的生命周期。備忘錄創(chuàng)建出來(lái)就要在最近的代碼中使用，要主動(dòng)管理它的生命周期，建立就要使用，不使用就要立刻刪除其引用，等待垃圾回收器對(duì)它的回收處理。

2．備忘錄的性能。不要頻繁建立備份的場(chǎng)景中使用備忘錄模式。

訪問(wèn)者模式：封裝一些作用于某種數(shù)據(jù)結(jié)構(gòu)中的各元素的操作，它可以在不改變數(shù)據(jù)結(jié)構(gòu)的前提下定義作用于這些元素的新的操作。

優(yōu)點(diǎn)：1.使得增加新的操作變得很容易，增加新的操作只需要增加新的訪問(wèn)類(lèi)。2.將有關(guān)的行為集中到一個(gè)訪問(wèn)者對(duì)象中，而不是分散到一個(gè)個(gè)元素類(lèi)中。3.訪問(wèn)者模式可以跨過(guò)幾個(gè)類(lèi)的等級(jí)結(jié)構(gòu)訪問(wèn)屬于不同等級(jí)結(jié)構(gòu)的成員類(lèi)。4．積累狀態(tài)。

缺點(diǎn)：增加新的元素類(lèi)變得困難；破壞封裝；違背依賴倒置原則。

應(yīng)用場(chǎng)景：1.一個(gè)對(duì)象結(jié)構(gòu)類(lèi)有很多類(lèi)對(duì)象，它們有不同的接口，當(dāng)這些對(duì)象實(shí)施依賴于具體類(lèi)的操作時(shí)，即使用迭代器模式不能勝任的場(chǎng)景下，可以采用訪問(wèn)者模式。

2.需要對(duì)一個(gè)對(duì)象結(jié)構(gòu)中的對(duì)象進(jìn)行很多不同且無(wú)關(guān)的操作，避免操作污染類(lèi)。3.業(yè)務(wù)要求遍歷多個(gè)不同的對(duì)象，這本身也是訪問(wèn)者模式的出發(fā)點(diǎn)，迭代器模式只能訪問(wèn)同類(lèi)或同接口的數(shù)據(jù)，而訪問(wèn)者模式是對(duì)迭代器模式的擴(kuò)充，可以遍歷不同的對(duì)象，執(zhí)行不同的操作。

狀態(tài)模式：當(dāng)一個(gè)對(duì)象內(nèi)在狀態(tài)改變時(shí)允許改變行為，這個(gè)對(duì)象看起來(lái)像改變了其類(lèi)型 優(yōu)點(diǎn)：結(jié)構(gòu)清晰；遵循設(shè)計(jì)原則；封裝性非常好。缺點(diǎn)：子類(lèi)太多，不易管理。

效果：1.狀態(tài)模式需要對(duì)每一個(gè)系統(tǒng)可能取得的狀態(tài)創(chuàng)建一個(gè)狀態(tài)類(lèi)的子類(lèi)。2.由于每一個(gè)狀態(tài)都被包裝到了類(lèi)里面，就可以不必采用過(guò)程性的處理方式，使長(zhǎng)篇累牘的條件轉(zhuǎn)移語(yǔ)句。

3.可以在系統(tǒng)的不同部分使用相同的一些狀態(tài)類(lèi)的對(duì)象。4.狀態(tài)模式會(huì)造成大量的小狀態(tài)類(lèi)，但是可以使程序免于大量的條件轉(zhuǎn)移語(yǔ)句，使程序?qū)嶋H上更易維護(hù)。

5.系統(tǒng)所選的狀態(tài)子類(lèi)均是從一個(gè)抽象狀態(tài)類(lèi)或借口繼承而來(lái)，JAVA語(yǔ)言的特性使得在Java語(yǔ)言中使用狀態(tài)模式較為完全，多態(tài)性原則是狀態(tài)模式的核心。

使用場(chǎng)景：對(duì)象的行為依賴于它所處的狀態(tài)，即行為隨狀態(tài)改變而改變的場(chǎng)景；對(duì)象在某個(gè)方法里依賴于一重或多重條件分支語(yǔ)句。

解釋器模式：給定一門(mén)語(yǔ)言，定義它的文法的一種表示，并定義一個(gè)解釋器，該解釋器使用該表示來(lái)解釋語(yǔ)言中的句子。

優(yōu)點(diǎn)：簡(jiǎn)單的語(yǔ)法分析工具；擴(kuò)展性，修改語(yǔ)法規(guī)則只要修改相應(yīng)的非終結(jié)符表達(dá)式即可，若擴(kuò)展語(yǔ)法，則只要增加非終結(jié)符類(lèi)即可。

缺點(diǎn)：解釋器模式會(huì)引起類(lèi)膨脹；采用遞歸調(diào)用的方法。

使用場(chǎng)景：重復(fù)發(fā)生的問(wèn)題可以使用解釋器模式；一個(gè)簡(jiǎn)單語(yǔ)法需要解釋的場(chǎng)景。

第二篇：Java設(shè)計(jì)模式學(xué)習(xí)心得

Java設(shè)計(jì)模式學(xué)習(xí)心得

閱讀次數(shù): 1584次 發(fā)布時(shí)間: 2010-04-10 14:52:13發(fā)布人: 網(wǎng)絡(luò)轉(zhuǎn)載

來(lái)源: 網(wǎng)絡(luò)轉(zhuǎn)載

整個(gè)設(shè)計(jì)模式貫穿一個(gè)原理:面對(duì)介面編程，而不是面對(duì)實(shí)現(xiàn)，（面向物件編程應(yīng)該改爲(wèi)面向介面編程）。目標(biāo)原則是:降低耦合，增強(qiáng)靈活性。

一、創(chuàng)建模式

1.設(shè)計(jì)模式之Factory(工廠方法和抽象工廠)

使用工廠模式就象使用new一樣頻繁.2.設(shè)計(jì)模式之Prototype(原型)

用原型實(shí)例指定創(chuàng)建物件的種類(lèi)，並且通過(guò)拷貝這些原型創(chuàng)建新的物件。

3.設(shè)計(jì)模式之Builder

汽車(chē)由車(chē)輪 方向盤(pán) 發(fā)動(dòng)機(jī)很多部件組成，同時(shí)，將這些部件組裝成汽車(chē)也是一件複雜的工作，Builder模式就是將這兩種情況分開(kāi)進(jìn)行。

4.設(shè)計(jì)模式之Singleton(單態(tài))

保證一個(gè)類(lèi)只有一個(gè)實(shí)例,並提供一個(gè)訪問(wèn)它的全局訪問(wèn)點(diǎn)

二、結(jié)構(gòu)模式

1.設(shè)計(jì)模式之Facade

可擴(kuò)展的使用JDBC針對(duì)不同的資料庫(kù)編程,Facade提供了一種靈活的實(shí)現(xiàn)。

2.設(shè)計(jì)模式之Proxy

以Jive爲(wèi)例,剖析代理模式在用戶級(jí)別授權(quán)機(jī)制上的應(yīng)用

3.設(shè)計(jì)模式之Adapter

使用類(lèi)再生的兩個(gè)方式:組合(new)和繼承(extends),這個(gè)已經(jīng)在“thinking in java”中提到過(guò)。

4.設(shè)計(jì)模式之Composite

就是將類(lèi)用樹(shù)形結(jié)構(gòu)組合成一個(gè)單位。你向別人介紹你是某單位，你是單位元元中的一個(gè)元素，別人和你做買(mǎi)賣(mài)，相當(dāng)於和單位做買(mǎi)賣(mài)。文章中還對(duì)Jive再進(jìn)行了剖析。

5.設(shè)計(jì)模式之Decorator

Decorator是個(gè)油漆工,給你的東東的外表刷上美麗的顔色。

6.設(shè)計(jì)模式之Bridge

將“牛郎織女”分開(kāi)(本應(yīng)在一起,分開(kāi)他們,形成兩個(gè)介面),在他們之間搭建一個(gè)橋(動(dòng)態(tài)的結(jié)合)

7.設(shè)計(jì)模式之Flyweight

提供Java運(yùn)行性能,降低小而大量重復(fù)的類(lèi)的開(kāi)銷(xiāo)。

三、行爲(wèi)模式

1.設(shè)計(jì)模式之Template

實(shí)際上向你介紹了爲(wèi)什麼要使用Java 抽象類(lèi),該模式原理簡(jiǎn)單,使用很普遍。

2.設(shè)計(jì)模式之Memento

很簡(jiǎn)單一個(gè)模式,就是在記憶體中保留原來(lái)資料的拷貝。

3.設(shè)計(jì)模式之Observer

介紹如何使用Java API提供的現(xiàn)成Observer

4.設(shè)計(jì)模式之Chain of Responsibility

各司其職的類(lèi)串成一串,好象擊鼓傳花,當(dāng)然如果自己能完成,就不要推委給下一個(gè)。

5.設(shè)計(jì)模式之Command

什麼是將行爲(wèi)封裝,Command是最好的說(shuō)明。

6.設(shè)計(jì)模式之State

狀態(tài)是編程中經(jīng)常碰到的實(shí)例,將狀態(tài)物件化,設(shè)立狀態(tài)變換器,便可在狀態(tài)中輕鬆切換。

7.設(shè)計(jì)模式之Strategy

不同演算法各自封裝,用戶端可隨意挑選需要的演算法。

8.設(shè)計(jì)模式之Mediator

Mediator很象十字路口的紅綠燈,每個(gè)車(chē)輛只需和紅綠燈交互就可以。

9.設(shè)計(jì)模式之Interpreter

主要用來(lái)對(duì)語(yǔ)言的分析,應(yīng)用機(jī)會(huì)不多。

10.設(shè)計(jì)模式之Visitor

訪問(wèn)者在進(jìn)行訪問(wèn)時(shí),完成一系列實(shí)質(zhì)性操作,而且還可以擴(kuò)展。

11.設(shè)計(jì)模式之Iterator

這個(gè)模式已經(jīng)被用來(lái)遍曆Collection中物件。使用頻率很高。在Java中無(wú)需專門(mén)闡述,在大多數(shù)場(chǎng)合也無(wú)需自己制造一個(gè)Iterator,只要將物件裝入Collection中，我們就直接可以使用Iterator模式。

第三篇：java設(shè)計(jì)模式考試題

一選擇題：共10分

1.Open-Close原則的含義是一個(gè)軟件實(shí)體(a)

A.應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉

2.是10道選擇題第一題考完了

二 簡(jiǎn)答題 共10分

1.什么是設(shè)計(jì)模式？

設(shè)計(jì)模式是從許多優(yōu)秀軟件系統(tǒng)中總結(jié)出的成功的可復(fù)用的設(shè)計(jì)方案。

2.設(shè)計(jì)模式的四個(gè)基本要素是什么，以及他們是什么含義？

名稱：

問(wèn)題：

方案：

效果：含義在書(shū)上p1

三 畫(huà)類(lèi)圖

14畫(huà)出命令模式的類(lèi)圖，并寫(xiě)出關(guān)鍵的代碼？

見(jiàn)書(shū)上17頁(yè)

15.畫(huà)出迭代器模式的類(lèi)圖，并寫(xiě)出關(guān)鍵的代碼？、見(jiàn)書(shū)上105頁(yè)

四寫(xiě)代碼學(xué)一個(gè)關(guān)于求職中心，通知求職者的問(wèn)題

這是一個(gè)觀察者模式，具體看看書(shū)

我的書(shū)是第五章的書(shū)上例題

2.是一個(gè)交通工具營(yíng)銷(xiāo)問(wèn)題；

應(yīng)該是外觀模式；見(jiàn)書(shū)上99頁(yè)，應(yīng)該就是個(gè)

這是我們學(xué)校的考試題，2012年

第四篇：JAVA設(shè)計(jì)模式之創(chuàng)建模式

設(shè)計(jì)模式之Builder

Builder模式定義: 將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離,使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示.Builder模式是一步一步創(chuàng)建一個(gè)復(fù)雜的對(duì)象,它允許用戶可以只通過(guò)指定復(fù)雜對(duì)象的類(lèi)型和內(nèi)容就可以構(gòu)建它們.用戶不知道內(nèi)部的具體構(gòu)建細(xì)節(jié).Builder模式是非常類(lèi)似抽象工廠模式,細(xì)微的區(qū)別大概只有在反復(fù)使用中才能體會(huì)到.為何使用?

是為了將構(gòu)建復(fù)雜對(duì)象的過(guò)程和它的部件解耦.注意: 是解耦過(guò)程和部件.因?yàn)橐粋€(gè)復(fù)雜的對(duì)象,不但有很多大量組成部分,如汽車(chē),有很多部件:車(chē)輪 方向盤(pán) 發(fā)動(dòng)機(jī)還有各種小零件等等,部件很多,但遠(yuǎn)不止這些,如何將這些部件裝配成一輛汽車(chē),這個(gè)裝配過(guò)程也很復(fù)雜(需要很好的組裝技術(shù)),Builder模式就是為了將部件和組裝過(guò)程分開(kāi).如何使用?

首先假設(shè)一個(gè)復(fù)雜對(duì)象是由多個(gè)部件組成的,Builder模式是把復(fù)雜對(duì)象的創(chuàng)建和部件的創(chuàng)建分別開(kāi)來(lái),分別用Builder類(lèi)和Director類(lèi)來(lái)表示.首先,需要一個(gè)接口,它定義如何創(chuàng)建復(fù)雜對(duì)象的各個(gè)部件: public interface Builder {

//創(chuàng)建部件A 比如創(chuàng)建汽車(chē)車(chē)輪

void buildPartA();

//創(chuàng)建部件B 比如創(chuàng)建汽車(chē)方向盤(pán)

void buildPartB();

//創(chuàng)建部件C 比如創(chuàng)建汽車(chē)發(fā)動(dòng)機(jī)

void buildPartC();

//返回最后組裝成品結(jié)果(返回最后裝配好的汽車(chē))

//成品的組裝過(guò)程不在這里進(jìn)行,而是轉(zhuǎn)移到下面的Director類(lèi)中進(jìn)行.//從而實(shí)現(xiàn)了解耦過(guò)程和部件

Product getResult();} 用Director構(gòu)建最后的復(fù)雜對(duì)象,而在上面Builder接口中封裝的是如何創(chuàng)建一個(gè)個(gè)部件(復(fù)雜對(duì)象是由這些部件組成的),也就是說(shuō)Director的內(nèi)容是如何將部件最后組裝成成品: public class Director {

private Builder builder;

public Director(Builder builder){

this.builder = builder;} // 將部件partA partB partC最后組成復(fù)雜對(duì)象 //這里是將車(chē)輪 方向盤(pán)和發(fā)動(dòng)機(jī)組裝成汽車(chē)的過(guò)程 public void construct(){

builder.buildPartA();

builder.buildPartB();

builder.buildPartC();

} } Builder的具體實(shí)現(xiàn)ConcreteBuilder: 通過(guò)具體完成接口Builder來(lái)構(gòu)建或裝配產(chǎn)品的部件;定義并明確它所要?jiǎng)?chuàng)建的是什么具體東西;提供一個(gè)可以重新獲取產(chǎn)品的接口: public class ConcreteBuilder implements Builder {

Part partA, partB, partC;public void buildPartA(){

//這里是具體如何構(gòu)建partA的代碼

};public void buildPartB(){

//這里是具體如何構(gòu)建partB的代碼 };public void buildPartC(){

//這里是具體如何構(gòu)建partB的代碼 };public Product getResult(){

//返回最后組裝成品結(jié)果 };} 復(fù)雜對(duì)象:產(chǎn)品Product: public interface Product { } 復(fù)雜對(duì)象的部件: public interface Part { }

我們看看如何調(diào)用Builder模式: ConcreteBuilder builder = new ConcreteBuilder();Director director = new Director(builder);

director.construct();Product product = builder.getResult();Builder模式的應(yīng)用

在Java實(shí)際使用中,我們經(jīng)常用到“池”(Pool)的概念,當(dāng)資源提供者無(wú)法提供足夠的資源,并且這些資源需要被很多用戶反復(fù)共享時(shí),就需要使用池.“池”實(shí)際是一段內(nèi)存,當(dāng)池中有一些復(fù)雜的資源的“斷肢”(比如數(shù)據(jù)庫(kù)的連接池,也許有時(shí)一個(gè)連接會(huì)中斷),如果循環(huán)再利用這些“斷肢”,將提高內(nèi)存使用效率,提高池的性能.修改Builder模式中Director類(lèi)使之能診斷“斷肢”斷在哪個(gè)部件上,再修復(fù)這個(gè)部件.設(shè)計(jì)模式之Factory

定義:提供創(chuàng)建對(duì)象的接口.為何使用?

工廠模式是我們最常用的模式了,著名的Jive論壇 ,就大量使用了工廠模式，工廠模式在Java程序系統(tǒng)可以說(shuō)是隨處可見(jiàn)。

為什么工廠模式是如此常用？因?yàn)楣S模式就相當(dāng)于創(chuàng)建實(shí)例對(duì)象的new，我們經(jīng)常要根據(jù)類(lèi)Class生成實(shí)例對(duì)象，如A a=new A()工廠模式也是用來(lái)創(chuàng)建實(shí)例對(duì)象的，所以以后new時(shí)就要多個(gè)心眼，是否可以考慮實(shí)用工廠模式，雖然這樣做，可能多做一些工作，但會(huì)給你系統(tǒng)帶來(lái)更大的可擴(kuò)展性和盡量少的修改量。我們以類(lèi)Sample為例，如果我們要?jiǎng)?chuàng)建Sample的實(shí)例對(duì)象: Sample sample=new Sample();可是，實(shí)際情況是，通常我們都要在創(chuàng)建sample實(shí)例時(shí)做點(diǎn)初始化的工作,比如賦值 查詢數(shù)據(jù)庫(kù)等。

首先，我們想到的是，可以使用Sample的構(gòu)造函數(shù)，這樣生成實(shí)例就寫(xiě)成: Sample sample=new Sample(參數(shù));但是，如果創(chuàng)建sample實(shí)例時(shí)所做的初始化工作不是象賦值這樣簡(jiǎn)單的事，可能是很長(zhǎng)一段代碼，如果也寫(xiě)入構(gòu)造函數(shù)中，那你的代碼很難看了（就需要Refactor重整）。為什么說(shuō)代碼很難看，初學(xué)者可能沒(méi)有這種感覺(jué)，我們分析如下，初始化工作如果是很長(zhǎng)一段代碼，說(shuō)明要做的工作很多，將很多工作裝入一個(gè)方法中，相當(dāng)于將很多雞蛋放在一個(gè)籃子里，是很危險(xiǎn)的，這也是有背于Java面向?qū)ο蟮脑瓌t，面向?qū)ο蟮姆庋b(Encapsulation)和分派(Delegation)告訴我們，盡量將長(zhǎng)的代碼分派“切割”成每段，將每段再“封裝”起來(lái)(減少段和段之間偶合聯(lián)系性)，這樣，就會(huì)將風(fēng)險(xiǎn)分散，以后如果需要修改，只要更改每段，不會(huì)再發(fā)生牽一動(dòng)百的事情。

在本例中，首先，我們需要將創(chuàng)建實(shí)例的工作與使用實(shí)例的工作分開(kāi), 也就是說(shuō)，讓創(chuàng)建實(shí)例所需要的大量初始化工作從Sample的構(gòu)造函數(shù)中分離出去。

這時(shí)我們就需要Factory工廠模式來(lái)生成對(duì)象了，不能再用上面簡(jiǎn)單new Sample(參數(shù))。還有,如果Sample有個(gè)繼承如MySample, 按照面向接口編程,我們需要將Sample抽象成一個(gè)接口.現(xiàn)在Sample是接口,有兩個(gè)子類(lèi)MySample 和HisSample.我們要實(shí)例化他們時(shí),如下: Sample mysample=new MySample();Sample hissample=new HisSample();隨著項(xiàng)目的深入,Sample可能還會(huì)“生出很多兒子出來(lái)”, 那么我們要對(duì)這些兒子一個(gè)個(gè)實(shí)例化,更糟糕的是,可能還要對(duì)以前的代碼進(jìn)行修改:加入后來(lái)生出兒子的實(shí)例.這在傳統(tǒng)程序中是無(wú)法避免的.但如果你一開(kāi)始就有意識(shí)使用了工廠模式,這些麻煩就沒(méi)有了.工廠方法

你會(huì)建立一個(gè)專門(mén)生產(chǎn)Sample實(shí)例的工廠: public class Factory{

public static Sample creator(int which){

//getClass 產(chǎn)生Sample 一般可使用動(dòng)態(tài)類(lèi)裝載裝入類(lèi)。if(which==1)

return new SampleA();else if(which==2)

return new SampleB();

} } 那么在你的程序中,如果要實(shí)例化Sample時(shí).就使用 Sample sampleA=Factory.creator(1);這樣,在整個(gè)就不涉及到Sample的具體子類(lèi),達(dá)到封裝效果,也就減少錯(cuò)誤修改的機(jī)會(huì),這個(gè)原理可以用很通俗的話來(lái)比喻:就是具體事情做得越多,越容易范錯(cuò)誤.這每個(gè)做過(guò)具體工作的人都深有體會(huì),相反,官做得越高,說(shuō)出的話越抽象越籠統(tǒng),范錯(cuò)誤可能性就越少.好象我們從編程序中也能悟出人生道理?呵呵.使用工廠方法 要注意幾個(gè)角色，首先你要定義產(chǎn)品接口，如上面的Sample,產(chǎn)品接口下有Sample接口的實(shí)現(xiàn)類(lèi),如SampleA,其次要有一個(gè)factory類(lèi)，用來(lái)生成產(chǎn)品Sample，如下圖，最右邊是生產(chǎn)的對(duì)象Sample：

進(jìn)一步稍微復(fù)雜一點(diǎn)，就是在工廠類(lèi)上進(jìn)行拓展，工廠類(lèi)也有繼承它的實(shí)現(xiàn)類(lèi)concreteFactory了。抽象工廠

工廠模式中有: 工廠方法(Factory Method)抽象工廠(Abstract Factory).這兩個(gè)模式區(qū)別在于需要?jiǎng)?chuàng)建對(duì)象的復(fù)雜程度上。如果我們創(chuàng)建對(duì)象的方法變得復(fù)雜了,如上面工廠方法中是創(chuàng)建一個(gè)對(duì)象Sample,如果我們還有新的產(chǎn)品接口Sample2.這里假設(shè)：Sample有兩個(gè)concrete類(lèi)SampleA和SamleB，而Sample2也有兩個(gè)concrete類(lèi)Sample2A和SampleB2 那么，我們就將上例中Factory變成抽象類(lèi),將共同部分封裝在抽象類(lèi)中,不同部分使用子類(lèi)實(shí)現(xiàn)，下面就是將上例中的Factory拓展成抽象工廠: public abstract class Factory{

public abstract Sample creator();

public abstract Sample2 creator(String name);} public class SimpleFactory extends Factory{

public Sample creator(){

.........return new SampleA } public Sample2 creator(String name){

.........return new Sample2A } } public class BombFactory extends Factory{

public Sample creator(){

......return new SampleB } public Sample2 creator(String name){

......return new Sample2B } }

從上面看到兩個(gè)工廠各自生產(chǎn)出一套Sample和Sample2,也許你會(huì)疑問(wèn)，為什么我不可以使用兩個(gè)工廠方法來(lái)分別生產(chǎn)Sample和Sample2? 抽象工廠還有另外一個(gè)關(guān)鍵要點(diǎn)，是因?yàn)?SimpleFactory內(nèi)，生產(chǎn)Sample和生產(chǎn)Sample2的方法之間有一定聯(lián)系，所以才要將這兩個(gè)方法捆綁在一個(gè)類(lèi)中，這個(gè)工廠類(lèi)有其本身特征，也許制造過(guò)程是統(tǒng)一的，比如：制造工藝比較簡(jiǎn)單，所以名稱叫SimpleFactory。在實(shí)際應(yīng)用中，工廠方法用得比較多一些，而且是和動(dòng)態(tài)類(lèi)裝入器組合在一起應(yīng)用，舉例

我們以Jive的ForumFactory為例，這個(gè)例子在前面的Singleton模式中我們討論過(guò)，現(xiàn)在再討論其工廠模式: public abstract class ForumFactory {

private static Object initLock = new Object();

private static String className = “com.jivesoftware.forum.database.DbForumFactory”;

private static ForumFactory factory = null;

public static ForumFactory getInstance(Authorization authorization){

//If no valid authorization passed in, return null.if(authorization == null){

return null;

}

//以下使用了Singleton 單態(tài)模式

if(factory == null){

synchronized(initLock){

if(factory == null){

......}

}

} try {

//動(dòng)態(tài)轉(zhuǎn)載類(lèi)

Class c = Class.forName(className);

factory =(ForumFactory)c.newInstance();} catch(Exception e){

return null;}

//Now, 返回 proxy.用來(lái)限制授權(quán)對(duì)forum的訪問(wèn)

return new ForumFactoryProxy(authorization, factory，factory.getPermissions(authorization));

}

//真正創(chuàng)建forum的方法由繼承forumfactory的子類(lèi)去完成.public abstract Forum createForum(String name, String description)

throws UnauthorizedException, ForumAlreadyExistsException;

....}

因?yàn)楝F(xiàn)在的Jive是通過(guò)數(shù)據(jù)庫(kù)系統(tǒng)存放論壇帖子等內(nèi)容數(shù)據(jù),如果希望更改為通過(guò)文件系統(tǒng)實(shí)現(xiàn),這個(gè)工廠方法ForumFactory就提供了提供動(dòng)態(tài)接口: private static String className = “com.jivesoftware.forum.database.DbForumFactory”;你可以使用自己開(kāi)發(fā)的創(chuàng)建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.在上面的一段代碼中一共用了三種模式,除了工廠模式外,還有Singleton單態(tài)模式,以及proxy模式,proxy模式主要用來(lái)授權(quán)用戶對(duì)forum的訪問(wèn),因?yàn)樵L問(wèn)forum有兩種人:一個(gè)是注冊(cè)用戶 一個(gè)是游客guest,那么那么相應(yīng)的權(quán)限就不一樣,而且這個(gè)權(quán)限是貫穿整個(gè)系統(tǒng)的,因此建立一個(gè)proxy,類(lèi)似網(wǎng)關(guān)的概念,可以很好的達(dá)到這個(gè)效果.看看Java寵物店中的CatalogDAOFactory: public class CatalogDAOFactory {

/**

* 本方法制定一個(gè)特別的子類(lèi)來(lái)實(shí)現(xiàn)DAO模式。

* 具體子類(lèi)定義是在J2EE的部署描述器中。

*/

public static CatalogDAO getDAO()throws CatalogDAOSysException {

CatalogDAO catDao = null;

try {

InitialContext ic = new InitialContext();//動(dòng)態(tài)裝入CATALOG_DAO_CLASS //可以定義自己的CATALOG_DAO_CLASS，從而在無(wú)需變更太多代碼 //的前提下，完成系統(tǒng)的巨大變更。

String className =(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);

catDao =(CatalogDAO)Class.forName(className).newInstance();

} catch(NamingException ne){

throw new CatalogDAOSysException(“

CatalogDAOFactory.getDAO: NamingException while

getting DAO type : n” + ne.getMessage());

} catch(Exception se){

throw new CatalogDAOSysException(“

CatalogDAOFactory.getDAO: Exception while getting

DAO type : n” + se.getMessage());

}

return catDao;

} } CatalogDAOFactory是典型的工廠方法，catDao是通過(guò)動(dòng)態(tài)類(lèi)裝入器className獲得CatalogDAOFactory具體實(shí)現(xiàn)子類(lèi)，這個(gè)實(shí)現(xiàn)子類(lèi)在Java寵物店是用來(lái)操作catalog數(shù)據(jù)庫(kù)，用戶可以根據(jù)數(shù)據(jù)庫(kù)的類(lèi)型不同，定制自己的具體實(shí)現(xiàn)子類(lèi)，將自己的子類(lèi)名給與CATALOG_DAO_CLASS變量就可以。

由此可見(jiàn)，工廠方法確實(shí)為系統(tǒng)結(jié)構(gòu)提供了非常靈活強(qiáng)大的動(dòng)態(tài)擴(kuò)展機(jī)制，只要我們更換一下具體的工廠方法，系統(tǒng)其他地方無(wú)需一點(diǎn)變換，就有可能將系統(tǒng)功能進(jìn)行改頭換面的變化。

設(shè)計(jì)模式之Prototype(原型)

定義: 用原型實(shí)例指定創(chuàng)建對(duì)象的種類(lèi),并且通過(guò)拷貝這些原型創(chuàng)建新的對(duì)象.Prototype模式允許一個(gè)對(duì)象再創(chuàng)建另外一個(gè)可定制的對(duì)象，根本無(wú)需知道任何如何創(chuàng)建的細(xì)節(jié),工作原理是:通過(guò)將一個(gè)原型對(duì)象傳給那個(gè)要發(fā)動(dòng)創(chuàng)建的對(duì)象，這個(gè)要發(fā)動(dòng)創(chuàng)建的對(duì)象通過(guò)請(qǐng)求原型對(duì)象拷貝它們自己來(lái)實(shí)施創(chuàng)建。如何使用? 因?yàn)镴ava中的提供clone()方法來(lái)實(shí)現(xiàn)對(duì)象的克隆(具體了解clone()按這里),所以Prototype模式實(shí)現(xiàn)一下子變得很簡(jiǎn)單.以勺子為例：

public abstract class AbstractSpoon implements Cloneable {

String spoonName;

public void setSpoonName(String spoonName){this.spoonName = spoonName;}

public String getSpoonName(){return this.spoonName;}

public Object clone()

{

Object object = null;

try {

object = super.clone();

} catch(CloneNotSupportedException exception){

System.err.println(“AbstractSpoon is not Cloneable”);

}

return object;

} } 有兩個(gè)具體實(shí)現(xiàn)(ConcretePrototype): public class SoupSpoon extends AbstractSpoon {

public SoupSpoon()

{

setSpoonName(“Soup Spoon”);

} } public class SaladSpoon extends AbstractSpoon {

public SaladSpoon()

{

setSpoonName(“Salad Spoon”);

} } 調(diào)用Prototype模式很簡(jiǎn)單: AbstractSpoon spoon = new SoupSpoon();AbstractSpoon spoon = new SaladSpoon();當(dāng)然也可以結(jié)合工廠模式來(lái)創(chuàng)建AbstractSpoon實(shí)例。

在Java中Prototype模式變成clone()方法的使用，由于Java的純潔的面向?qū)ο筇匦?，使得在Java中使用設(shè)計(jì)模式變得很自然，兩者已經(jīng)幾乎是渾然一體了。這反映在很多模式上，如Interator遍歷模式。

設(shè)計(jì)模式之Singleton(單態(tài))

定義: Singleton模式主要作用是保證在Java應(yīng)用程序中，一個(gè)類(lèi)Class只有一個(gè)實(shí)例存在。在很多操作中，比如建立目錄 數(shù)據(jù)庫(kù)連接都需要這樣的單線程操作。

還有, singleton能夠被狀態(tài)化;這樣，多個(gè)單態(tài)類(lèi)在一起就可以作為一個(gè)狀態(tài)倉(cāng)庫(kù)一樣向外提供服務(wù)，比如，你要論壇中的帖子計(jì)數(shù)器，每次瀏覽一次需要計(jì)數(shù)，單態(tài)類(lèi)能否保持住這個(gè)計(jì)數(shù)，并且能synchronize的安全自動(dòng)加1，如果你要把這個(gè)數(shù)字永久保存到數(shù)據(jù)庫(kù)，你可以在不修改單態(tài)接口的情況下方便的做到。

另外方面，Singleton也能夠被無(wú)狀態(tài)化。提供工具性質(zhì)的功能，Singleton模式就為我們提供了這樣實(shí)現(xiàn)的可能。使用Singleton的好處還在于可以節(jié)省內(nèi)存，因?yàn)樗拗屏藢?shí)例的個(gè)數(shù)，有利于Java垃圾回收（garbage collection）。

我們常?？吹焦S模式中類(lèi)裝入器(class loader)中也用Singleton模式實(shí)現(xiàn)的,因?yàn)楸谎b入的類(lèi)實(shí)際也屬于資源。如何使用?

一般Singleton模式通常有幾種形式: public class Singleton {

private Singleton(){}

//在自己內(nèi)部定義自己一個(gè)實(shí)例，是不是很奇怪？

//注意這是private 只供內(nèi)部調(diào)用

private static Singleton instance = new Singleton();

}

第二種形式: public class Singleton {

private static Singleton instance = null;public static synchronized Singleton getInstance(){

//這個(gè)方法比上面有所改進(jìn)，不用每次都進(jìn)行生成對(duì)象，只是第一次

//使用時(shí)生成實(shí)例，提高了效率！if(instance==null)

instance＝new Singleton();return instance;} //這里提供了一個(gè)供外部訪問(wèn)本class的靜態(tài)方法，可以直接訪問(wèn)

public static Singleton getInstance(){

return instance;

} }

使用Singleton.getInstance()可以訪問(wèn)單態(tài)類(lèi)。

上面第二中形式是lazy initialization，也就是說(shuō)第一次調(diào)用時(shí)初始Singleton，以后就不用再生成了。

注意到lazy initialization形式中的synchronized，這個(gè)synchronized很重要，如果沒(méi)有synchronized，那么使用getInstance()是有可能得到多個(gè)Singleton實(shí)例。關(guān)于lazy initialization的Singleton有很多涉及double-checked locking(DCL)的討論，有興趣者進(jìn)一步研究。

一般認(rèn)為第一種形式要更加安全些。使用Singleton注意事項(xiàng)：

有時(shí)在某些情況下，使用Singleton并不能達(dá)到Singleton的目的，如有多個(gè)Singleton對(duì)象同時(shí)被不同的類(lèi)裝入器裝載；在EJB這樣的分布式系統(tǒng)中使用也要注意這種情況，因?yàn)镋JB是跨服務(wù)器，跨JVM的。

我們以SUN公司的寵物店源碼(Pet Store 1.3.1)的ServiceLocator為例稍微分析一下：

在Pet Store中ServiceLocator有兩種，一個(gè)是EJB目錄下；一個(gè)是WEB目錄下，我們檢查這兩個(gè)ServiceLocator會(huì)發(fā)現(xiàn)內(nèi)容差不多，都是提供EJB的查詢定位服務(wù)，可是為什么要分開(kāi)呢？仔細(xì)研究對(duì)這兩種ServiceLocator才發(fā)現(xiàn)區(qū)別：在WEB中的ServiceLocator的采取Singleton模式，ServiceLocator屬于資源定位，理所當(dāng)然應(yīng)該使用Singleton模式。但是在EJB中，Singleton模式已經(jīng)失去作用，所以ServiceLocator才分成兩種，一種面向WEB服務(wù)的，一種是面向EJB服務(wù)的。

Singleton模式看起來(lái)簡(jiǎn)單，使用方法也很方便，但是真正用好，是非常不容易，需要對(duì)Java的類(lèi) 線程 內(nèi)存等概念有相當(dāng)?shù)牧私?。進(jìn)一步深入可參考：

Double-checked locking and the Singleton pattern When is a singleton not a singleton?

第五篇：JAVA學(xué)習(xí)書(shū)籍- 設(shè)計(jì)模式

談到設(shè)計(jì)模式很多人多會(huì)推薦GOF 的那本，該書(shū)在Amzon上是五星級(jí)的推薦書(shū)籍。不過(guò)對(duì)于學(xué)習(xí)java 沒(méi)多久的、特別是java 初學(xué)者，我很不推薦這本書(shū)。主要是該書(shū)的例子基本都是C++的，很多細(xì)節(jié)沒(méi)有講述得足夠清楚。

我給大家推薦的第一本是閻宏博士的《Java 與模式》，它是第一本中國(guó)人自己寫(xiě)的關(guān)于設(shè)計(jì)模式的書(shū)籍，寫(xiě)的比較有趣，融合了很多中

華民族的文化和觀念，例子、類(lèi)圖都比較多，且相對(duì)簡(jiǎn)單！非常不錯(cuò)的入門(mén)書(shū)籍――又是大塊頭哦！

其次我推薦Wiley 出版社出版的《Pattern In Java》一套三本，我才看了第一本，好像第二本不怎么樣，第三本還不錯(cuò)！

第三本是中文翻譯版的關(guān)于多線程模式的（很難得的中文翻譯版）中國(guó)鐵道出版社2003 年出版的《Java 多線程設(shè)計(jì)模式》，將多線程模

式講得非常淺顯，配有大量的圖例，每章都有習(xí)題，最后有答案！我研究多線程模式就是由它開(kāi)始的！

第四本，今年出版的Head First 系列的《Head First Design Pattern》，秉承Head First 系列圖書(shū)的優(yōu)點(diǎn)，大量的類(lèi)圖、豐富的實(shí)例、有趣的注解，值得購(gòu)買(mǎi)！

其次在J2EE 方向你可以研究閱讀Addison Wesley 2002 年出版的《Patterns of Enterprise Application Architecture》，眾多大腕的作品，講企業(yè)消息集成的！Sun 提供的《J2EE PATTERNS SL500》也很好！晚了推薦那一本Amzon 4 星半的《Holub on patterns》，大師的作品，提供了，很值得研究的例子，不過(guò)對(duì)上面四本不是很熟悉的讀者，最好不要讀它！可能會(huì)讓你比較累！

我學(xué)習(xí)設(shè)計(jì)模式經(jīng)過(guò)一段很曲折的路線，前前后后大約看了20 本，閻宏博士的《Java 與模式》我看了4 遍，還排除我第一次基本沒(méi)看

懂的看！記得研一時(shí)老師給我們講了GOF 的那本，作為選修課，我和它們計(jì)算機(jī)系的碩士、博士們一起，到最后一個(gè)班40－50 個(gè)人，不

超過(guò)3 個(gè)人明白，我也沒(méi)有明白任何一點(diǎn)（基礎(chǔ)差吧――主要我對(duì)C++語(yǔ)言一點(diǎn)都不了解），憑我不伏輸?shù)男愿?，我認(rèn)為我對(duì)java 語(yǔ)言理

解還可以，我就借了《Java 與模式》，結(jié)果還是基本沒(méi)看懂。很有幸的是讀研三時(shí)，聽(tīng)過(guò)了上交大饒若楠老師關(guān)于Java OOP 語(yǔ)言的講座，我懂了組合書(shū)籍模式等三種設(shè)計(jì)模式后，對(duì)其它模式有了強(qiáng)烈的興趣和要征服它的愿望！工作后我買(mǎi)的第一本就是《Java 與模式》，第一遍花了2 個(gè)月研究了這個(gè)1000 多頁(yè)的大塊頭，后來(lái)第三遍15 天左右就可以搞定，筆記記了一大本！從此一發(fā)不可收拾。

選對(duì)書(shū)、埋頭研究。相信很快就會(huì)入門(mén)的！

學(xué)習(xí)Java 語(yǔ)言8 個(gè)簡(jiǎn)單的部分，這只是我們研究Java 語(yǔ)言的開(kāi)始！這些都懂了充其量一個(gè)java 程序員而已，后面的路很長(zhǎng)很長(zhǎng)！我們

可以繼續(xù)研究數(shù)據(jù)庫(kù)實(shí)現(xiàn)的源代碼、Servlet 服務(wù)器的源代碼、RMI、EJB、JNDI、面向方面編程、重構(gòu)、ANT 工具、Eclipse 工具、Spring

工具、JBoss、JOnAS、Apache Geronimo 等J2EE 服務(wù)器！研究了這些你可能會(huì)成為一個(gè)出色的J2EE Architecture！你可以繼續(xù)研究剖

析器、編譯器、JNODE（java 寫(xiě)的操作系統(tǒng)）