JAVA設(shè)計(jì)模式與J2EE設(shè)計(jì)模式

1、1. JAVA設(shè)計(jì)模式簡(jiǎn)介1.1. 創(chuàng)建型模式1.1.1. Abstract Factory抽象工廠模式追MM少不了請(qǐng)吃飯了，麥當(dāng)勞的雞翅和肯德基的雞翅都是MM愛(ài)吃的東西，雖然口味有所不同，但不管你帶MM去麥當(dāng)勞或肯德基，只管向服務(wù)員說(shuō)“來(lái)四個(gè)雞翅”就行了。麥當(dāng)勞和肯德基就是生產(chǎn)雞翅的Factory客戶類和工廠類分開(kāi)。消費(fèi)者任何時(shí)候需要某種產(chǎn)品，只需向工廠請(qǐng)求即可。消費(fèi)者無(wú)須修改就可以接納新產(chǎn)品。缺點(diǎn)是當(dāng)產(chǎn)品修改時(shí)，工廠類也要做相應(yīng)的修改。如：如何創(chuàng)建及如何向客戶端提供。1.1.2. Builder建造模式MM最愛(ài)聽(tīng)的就是“我愛(ài)你”這句話了，見(jiàn)到不同地方的MM,要能夠用她們的方言跟她說(shuō)這句話哦

2、，我有一個(gè)多種語(yǔ)言翻譯機(jī)，上面每種語(yǔ)言都有一個(gè)按鍵，見(jiàn)到MM我只要按對(duì)應(yīng)的鍵，它就能夠用相應(yīng)的語(yǔ)言說(shuō)出“我愛(ài)你”這句話了，國(guó)外的MM也可以輕松搞掂，這就是我的“我愛(ài)你”builder。（這一定比美軍在伊拉克用的翻譯機(jī)好賣）將產(chǎn)品的內(nèi)部表象和產(chǎn)品的生成過(guò)程分割開(kāi)來(lái)，從而使一個(gè)建造過(guò)程生成具有不同的內(nèi)部表象的產(chǎn)品對(duì)象。建造模式使得產(chǎn)品內(nèi)部表象可以獨(dú)立的變化，客戶不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)。建造模式可以強(qiáng)制實(shí)行一種分步驟進(jìn)行的建造過(guò)程。1.1.3. Factory Method工廠方法模式請(qǐng)MM去麥當(dāng)勞吃漢堡，不同的MM有不同的口味，要每個(gè)都記住是一件煩人的事情，我一般采用Factory Metho

3、d模式，帶著MM到服務(wù)員那兒，說(shuō)“要一個(gè)漢堡”，具體要什么樣的漢堡呢，讓MM直接跟服務(wù)員說(shuō)就行了。核心工廠類不再負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，而是將具體創(chuàng)建的工作交給子類去做，成為一個(gè)抽象工廠角色，僅負(fù)責(zé)給出具體工廠類必須實(shí)現(xiàn)的接口，而不接觸哪一個(gè)產(chǎn)品類應(yīng)當(dāng)被實(shí)例化這種細(xì)節(jié)。1.1.4. Prototype原始模型模式跟MM用QQ聊天，一定要說(shuō)些深情的話語(yǔ)了，我搜集了好多肉麻的情話，需要時(shí)只要copy出來(lái)放到QQ里面就行了，這就是我的情話prototype了。（100塊錢(qián)一份，你要不要）通過(guò)給出一個(gè)原型對(duì)象來(lái)指明所要?jiǎng)?chuàng)建的對(duì)象的類型，然后用復(fù)制這個(gè)原型對(duì)象的方法創(chuàng)建出更多同類型的對(duì)象。原始模型模式允許動(dòng)

4、態(tài)的增加或減少產(chǎn)品類，產(chǎn)品類不需要非得有任何事先確定的等級(jí)結(jié)構(gòu)，原始模型模式適用于任何的等級(jí)結(jié)構(gòu)。缺點(diǎn)是每一個(gè)類都必須配備一個(gè)克隆方法。1.1.5. Singleton單例模式俺有6個(gè)漂亮的老婆，她們的老公都是我，我就是我們家里的老公Sigleton，她們只要說(shuō)道“老公”，都是指的同一個(gè)人，那就是我(剛才做了個(gè)夢(mèng)啦，哪有這么好的事)單例模式確保某一個(gè)類只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例單例模式。單例模式只應(yīng)在有真正的“單一實(shí)例”的需求時(shí)才可使用1.2. 結(jié)構(gòu)型模式1.2.1. Adapter適配器（變壓器）模式在朋友聚會(huì)上碰到了一個(gè)美女Sarah，從香港來(lái)的，可我不會(huì)說(shuō)粵語(yǔ)，

5、她不會(huì)說(shuō)普通話，只好求助于我的朋友kent了，他作為我和Sarah之間的Adapter，讓我和Sarah可以相互交談了(也不知道他會(huì)不會(huì)耍我)把一個(gè)類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無(wú)法一起工作的兩個(gè)類能夠一起工作。適配類可以根據(jù)參數(shù)返還一個(gè)合適的實(shí)例給客戶端。1.2.2. Bridge橋梁模式早上碰到MM，要說(shuō)早上好，晚上碰到MM，要說(shuō)晚上好；碰到MM穿了件新衣服，要說(shuō)你的衣服好漂亮哦，碰到MM新做的發(fā)型，要說(shuō)你的頭發(fā)好漂亮哦。不要問(wèn)我“早上碰到MM新做了個(gè)發(fā)型怎么說(shuō)”這種問(wèn)題，自己用BRIDGE組合一下不就行了將抽象化與實(shí)現(xiàn)化脫耦，使得二者可以獨(dú)立的變化，

6、也就是說(shuō)將他們之間的強(qiáng)關(guān)聯(lián)變成弱關(guān)聯(lián)，也就是指在一個(gè)軟件系統(tǒng)的抽象化和實(shí)現(xiàn)化之間使用組合/聚合關(guān)系而不是繼承關(guān)系，從而使兩者可以獨(dú)立的變化。1.2.3. Composite合成模式Mary今天過(guò)生日?！拔疫^(guò)生日，你要送我一件禮物?！薄班?，好吧，去商店，你自己挑。”“這件T恤挺漂亮，買(mǎi)，這條裙子好看，買(mǎi)，這個(gè)包也不錯(cuò)，買(mǎi)?！薄拔?，買(mǎi)了三件了呀，我只答應(yīng)送一件禮物的哦?！薄笆裁囱?，T恤加裙子加包包，正好配成一套呀，小姐，麻煩你包起來(lái)?！薄啊?，MM都會(huì)用Composite模式了，你會(huì)了沒(méi)有？合成模式將對(duì)象組織到樹(shù)結(jié)構(gòu)中，可以用來(lái)描述整體與部分的關(guān)系。合成模式就是一個(gè)處理對(duì)象的樹(shù)結(jié)構(gòu)的模式。合成模式把

7、部分與整體的關(guān)系用樹(shù)結(jié)構(gòu)表示出來(lái)。合成模式使得客戶端把一個(gè)個(gè)單獨(dú)的成分對(duì)象和由他們復(fù)合而成的合成對(duì)象同等看待。1.2.4. Decorator裝飾模式Mary過(guò)完輪到Sarly過(guò)生日，還是不要叫她自己挑了，不然這個(gè)月伙食費(fèi)肯定玩完，拿出我去年在華山頂上照的照片，在背面寫(xiě)上“最好的的禮物，就是愛(ài)你的Fita”，再到街上禮品店買(mǎi)了個(gè)像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術(shù)設(shè)計(jì)的Mike設(shè)計(jì)了一個(gè)漂亮的盒子裝起來(lái)，我們都是Decorator，最終都在修飾我這個(gè)人呀，怎么樣，看懂了嗎？裝飾模式以對(duì)客戶端透明的方式擴(kuò)展對(duì)象的功能，是繼承關(guān)系的一個(gè)替代方案，提供比繼承更多的靈活性。動(dòng)態(tài)給一個(gè)對(duì)象增加

8、功能，這些功能可以再動(dòng)態(tài)的撤消。增加由一些基本功能的排列組合而產(chǎn)生的非常大量的功能。1.2.5. Facade門(mén)面模式我有一個(gè)專業(yè)的Nikon相機(jī)，我就喜歡自己手動(dòng)調(diào)光圈、快門(mén)，這樣照出來(lái)的照片才專業(yè)，但MM可不懂這些，教了半天也不會(huì)。幸好相機(jī)有Facade設(shè)計(jì)模式，把相機(jī)調(diào)整到自動(dòng)檔，只要對(duì)準(zhǔn)目標(biāo)按快門(mén)就行了，一切由相機(jī)自動(dòng)調(diào)整，這樣MM也可以用這個(gè)相機(jī)給我拍張照片了。外部與一個(gè)子系統(tǒng)的通信必須通過(guò)一個(gè)統(tǒng)一的門(mén)面對(duì)象進(jìn)行。門(mén)面模式提供一個(gè)高層次的接口，使得子系統(tǒng)更易于使用。每一個(gè)子系統(tǒng)只有一個(gè)門(mén)面類，而且此門(mén)面類只有一個(gè)實(shí)例，也就是說(shuō)它是一個(gè)單例模式。但整個(gè)系統(tǒng)可以有多個(gè)門(mén)面類。1.2.6.

9、 Flyweight享元模式每天跟MM發(fā)短信，手指都累死了，最近買(mǎi)了個(gè)新手機(jī)，可以把一些常用的句子存在手機(jī)里，要用的時(shí)候，直接拿出來(lái)，在前面加上MM的名字就可以發(fā)送了，再不用一個(gè)字一個(gè)字敲了。共享的句子就是Flyweight，MM的名字就是提取出來(lái)的外部特征，根據(jù)上下文情況使用。FLYWEIGHT在拳擊比賽中指最輕量級(jí)。享元模式以共享的方式高效的支持大量的細(xì)粒度對(duì)象。享元模式能做到共享的關(guān)鍵是區(qū)分內(nèi)蘊(yùn)狀態(tài)和外蘊(yùn)狀態(tài)。內(nèi)蘊(yùn)狀態(tài)存儲(chǔ)在享元內(nèi)部，不會(huì)隨環(huán)境的改變而有所不同。外蘊(yùn)狀態(tài)是隨環(huán)境的改變而改變的。外蘊(yùn)狀態(tài)不能影響內(nèi)蘊(yùn)狀態(tài)，它們是相互獨(dú)立的。將可以共享的狀態(tài)和不可以共享的狀態(tài)從常規(guī)類中區(qū)分開(kāi)來(lái)

10、，將不可以共享的狀態(tài)從類里剔除出去?？蛻舳瞬豢梢灾苯觿?chuàng)建被共享的對(duì)象，而應(yīng)當(dāng)使用一個(gè)工廠對(duì)象負(fù)責(zé)創(chuàng)建被共享的對(duì)象。享元模式大幅度的降低內(nèi)存中對(duì)象的數(shù)量。1.2.7. Proxy代理模式跟MM在網(wǎng)上聊天，一開(kāi)頭總是“hi,你好”,“你從哪兒來(lái)呀？”“你多大了？”“身高多少呀？”這些話，真煩人，寫(xiě)個(gè)程序做為我的Proxy吧，凡是接收到這些話都設(shè)置好了自動(dòng)的回答，接收到其他的話時(shí)再通知我回答，怎么樣，酷吧。代理模式給某一個(gè)對(duì)象提供一個(gè)代理對(duì)象，并由代理對(duì)象控制對(duì)源對(duì)象的引用。代理就是一個(gè)人或一個(gè)機(jī)構(gòu)代表另一個(gè)人或者一個(gè)機(jī)構(gòu)采取行動(dòng)。某些情況下，客戶不想或者不能夠直接引用一個(gè)對(duì)象，代理對(duì)象可以在客戶和

11、目標(biāo)對(duì)象直接起到中介的作用?？蛻舳朔直娌怀龃碇黝}對(duì)象與真實(shí)主題對(duì)象。代理模式可以并不知道真正的被代理對(duì)象，而僅僅持有一個(gè)被代理對(duì)象的接口，這時(shí)候代理對(duì)象不能夠創(chuàng)建被代理對(duì)象，被代理對(duì)象必須有系統(tǒng)的其他角色代為創(chuàng)建并傳入。1.3. 行為型模式1.3.1. Chain Of Responsibility責(zé)任鏈模式晚上去上英語(yǔ)課，為了好開(kāi)溜坐到了最后一排，哇，前面坐了好幾個(gè)漂亮的MM哎，找張紙條，寫(xiě)上“Hi,可以做我的女朋友嗎？如果不愿意請(qǐng)向前傳”，紙條就一個(gè)接一個(gè)的傳上去了，糟糕，傳到第一排的MM把紙條傳給老師了，聽(tīng)說(shuō)是個(gè)老處女呀，快跑!在責(zé)任鏈模式中，很多對(duì)象由每一個(gè)對(duì)象對(duì)其下家的引用而接起來(lái)

12、形成一條鏈。請(qǐng)求在這個(gè)鏈上傳遞，直到鏈上的某一個(gè)對(duì)象決定處理此請(qǐng)求?？蛻舨⒉恢梨溕系哪囊粋€(gè)對(duì)象最終處理這個(gè)請(qǐng)求，系統(tǒng)可以在不影響客戶端的情況下動(dòng)態(tài)的重新組織鏈和分配責(zé)任。處理者有兩個(gè)選擇：承擔(dān)責(zé)任或者把責(zé)任推給下家。一個(gè)請(qǐng)求可以最終不被任何接收端對(duì)象所接受。1.3.2. Command命令模式俺有一個(gè)MM家里管得特別嚴(yán)，沒(méi)法見(jiàn)面，只好借助于她弟弟在我們倆之間傳送信息，她對(duì)我有什么指示，就寫(xiě)一張紙條讓她弟弟帶給我。這不，她弟弟又傳送過(guò)來(lái)一個(gè)COMMAND，為了感謝他，我請(qǐng)他吃了碗雜醬面，哪知道他說(shuō)：“我同時(shí)給我姐姐三個(gè)男朋友送COMMAND，就數(shù)你最小氣，才請(qǐng)我吃面?！保钅Ｊ桨岩粋€(gè)請(qǐng)求或者

13、操作封裝到一個(gè)對(duì)象中。命令模式把發(fā)出命令的責(zé)任和執(zhí)行命令的責(zé)任分割開(kāi)，委派給不同的對(duì)象。命令模式允許請(qǐng)求的一方和發(fā)送的一方獨(dú)立開(kāi)來(lái)，使得請(qǐng)求的一方不必知道接收請(qǐng)求的一方的接口，更不必知道請(qǐng)求是怎么被接收，以及操作是否執(zhí)行，何時(shí)被執(zhí)行以及是怎么被執(zhí)行的。系統(tǒng)支持命令的撤消。1.3.3. Interpreter解釋器模式俺有一個(gè)泡MM真經(jīng)，上面有各種泡MM的攻略，比如說(shuō)去吃西餐的步驟、去看電影的方法等等，跟MM約會(huì)時(shí)，只要做一個(gè)Interpreter，照著上面的腳本執(zhí)行就可以了。給定一個(gè)語(yǔ)言后，解釋器模式可以定義出其文法的一種表示，并同時(shí)提供一個(gè)解釋器?？蛻舳丝梢允褂眠@個(gè)解釋器來(lái)解釋這個(gè)語(yǔ)言中的句

14、子。解釋器模式將描述怎樣在有了一個(gè)簡(jiǎn)單的文法后，使用模式設(shè)計(jì)解釋這些語(yǔ)句。在解釋器模式里面提到的語(yǔ)言是指任何解釋器對(duì)象能夠解釋的任何組合。在解釋器模式中需要定義一個(gè)代表文法的命令類的等級(jí)結(jié)構(gòu)，也就是一系列的組合規(guī)則。每一個(gè)命令對(duì)象都有一個(gè)解釋方法，代表對(duì)命令對(duì)象的解釋。命令對(duì)象的等級(jí)結(jié)構(gòu)中的對(duì)象的任何排列組合都是一個(gè)語(yǔ)言。1.3.4. Iterator迭代子模式我愛(ài)上了Mary，不顧一切的向她求婚。Mary：“想要我跟你結(jié)婚，得答應(yīng)我的條件”我：“什么條件我都答應(yīng)，你說(shuō)吧”Mary：“我看上了那個(gè)一克拉的鉆石”我：“我買(mǎi)，我買(mǎi)，還有嗎？”Mary：“我看上了湖邊的那棟別墅”我：“我買(mǎi)，我買(mǎi)，還

15、有嗎？”Mary：“我看上那輛法拉利跑車”我腦袋嗡的一聲，坐在椅子上，一咬牙：“我買(mǎi)，我買(mǎi)，還有嗎？”迭代子模式可以順序訪問(wèn)一個(gè)聚集中的元素而不必暴露聚集的內(nèi)部表象。多個(gè)對(duì)象聚在一起形成的總體稱之為聚集，聚集對(duì)象是能夠包容一組對(duì)象的容器對(duì)象。迭代子模式將迭代邏輯封裝到一個(gè)獨(dú)立的子對(duì)象中，從而與聚集本身隔開(kāi)。迭代子模式簡(jiǎn)化了聚集的界面。每一個(gè)聚集對(duì)象都可以有一個(gè)或一個(gè)以上的迭代子對(duì)象，每一個(gè)迭代子的迭代狀態(tài)可以是彼此獨(dú)立的。迭代算法可以獨(dú)立于聚集角色變化。1.3.5. Mediator調(diào)停者模式四個(gè)MM打麻將，相互之間誰(shuí)應(yīng)該給誰(shuí)多少錢(qián)算不清楚了，幸虧當(dāng)時(shí)我在旁邊，按照各自的籌碼數(shù)算錢(qián)，賺了錢(qián)的從

16、我這里拿，賠了錢(qián)的也付給我，一切就OK啦，俺得到了四個(gè)MM的電話。調(diào)停者模式包裝了一系列對(duì)象相互作用的方式，使得這些對(duì)象不必相互明顯作用。從而使他們可以松散偶合。當(dāng)某些對(duì)象之間的作用發(fā)生改變時(shí)，不會(huì)立即影響其他的一些對(duì)象之間的作用。保證這些作用可以彼此獨(dú)立的變化。調(diào)停者模式將多對(duì)多的相互作用轉(zhuǎn)化為一對(duì)多的相互作用。調(diào)停者模式將對(duì)象的行為和協(xié)作抽象化，把對(duì)象在小尺度的行為上與其他對(duì)象的相互作用分開(kāi)處理。1.3.6. Memento備忘錄模式同時(shí)跟幾個(gè)MM聊天時(shí)，一定要記清楚剛才跟MM說(shuō)了些什么話，不然MM發(fā)現(xiàn)了會(huì)不高興的哦，幸虧我有個(gè)備忘錄，剛才與哪個(gè)MM說(shuō)了什么話我都拷貝一份放到備忘錄里面保存

17、，這樣可以隨時(shí)察看以前的記錄啦。備忘錄對(duì)象是一個(gè)用來(lái)存儲(chǔ)另外一個(gè)對(duì)象內(nèi)部狀態(tài)的快照的對(duì)象。備忘錄模式的用意是在不破壞封裝的條件下，將一個(gè)對(duì)象的狀態(tài)捉住，并外部化，存儲(chǔ)起來(lái)，從而可以在將來(lái)合適的時(shí)候把這個(gè)對(duì)象還原到存儲(chǔ)起來(lái)的狀態(tài)。1.3.7. Observer觀察者模式想知道咱們公司最新MM情報(bào)嗎？加入公司的MM情報(bào)郵件組就行了，tom負(fù)責(zé)搜集情報(bào)，他發(fā)現(xiàn)的新情報(bào)不用一個(gè)一個(gè)通知我們，直接發(fā)布給郵件組，我們作為訂閱者（觀察者）就可以及時(shí)收到情報(bào)啦觀察者模式定義了一種一隊(duì)多的依賴關(guān)系，讓多個(gè)觀察者對(duì)象同時(shí)監(jiān)聽(tīng)某一個(gè)主題對(duì)象。這個(gè)主題對(duì)象在狀態(tài)上發(fā)生變化時(shí)，會(huì)通知所有觀察者對(duì)象，使他們能夠自動(dòng)更新自

18、己。1.3.8. State狀態(tài)模式跟MM交往時(shí)，一定要注意她的狀態(tài)哦，在不同的狀態(tài)時(shí)她的行為會(huì)有不同，比如你約她今天晚上去看電影，對(duì)你沒(méi)興趣的MM就會(huì)說(shuō)“有事情啦”，對(duì)你不討厭但還沒(méi)喜歡上的MM就會(huì)說(shuō)“好啊，不過(guò)可以帶上我同事么？”，已經(jīng)喜歡上你的MM就會(huì)說(shuō)“幾點(diǎn)鐘？看完電影再去泡吧怎么樣？”，當(dāng)然你看電影過(guò)程中表現(xiàn)良好的話，也可以把MM的狀態(tài)從不討厭不喜歡變成喜歡哦。狀態(tài)模式允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變的時(shí)候改變行為。這個(gè)對(duì)象看上去象是改變了它的類一樣。狀態(tài)模式把所研究的對(duì)象的行為包裝在不同的狀態(tài)對(duì)象里，每一個(gè)狀態(tài)對(duì)象都屬于一個(gè)抽象狀態(tài)類的一個(gè)子類。狀態(tài)模式的意圖是讓一個(gè)對(duì)象在其內(nèi)部狀態(tài)改

19、變的時(shí)候，其行為也隨之改變。狀態(tài)模式需要對(duì)每一個(gè)系統(tǒng)可能取得的狀態(tài)創(chuàng)立一個(gè)狀態(tài)類的子類。當(dāng)系統(tǒng)的狀態(tài)變化時(shí)，系統(tǒng)便改變所選的子類。1.3.9. Strategy策略模式跟不同類型的MM約會(huì)，要用不同的策略，有的請(qǐng)電影比較好，有的則去吃小吃效果不錯(cuò)，有的去海邊浪漫最合適，單目的都是為了得到MM的芳心，我的追MM錦囊中有好多Strategy哦。策略模式針對(duì)一組算法，將每一個(gè)算法封裝到具有共同接口的獨(dú)立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發(fā)生變化。策略模式把行為和環(huán)境分開(kāi)。環(huán)境類負(fù)責(zé)維持和查詢行為類，各種算法在具體的策略類中提供。由于算法和環(huán)境獨(dú)立開(kāi)來(lái)，算法

20、的增減，修改都不會(huì)影響到環(huán)境和客戶端。1.3.10. Template Method模板方法模式看過(guò)如何說(shuō)服女生上床這部經(jīng)典文章嗎？女生從認(rèn)識(shí)到上床的不變的步驟分為巧遇、打破僵局、展開(kāi)追求、接吻、前戲、動(dòng)手、愛(ài)撫、進(jìn)去八大步驟(Template method)，但每個(gè)步驟針對(duì)不同的情況，都有不一樣的做法，這就要看你隨機(jī)應(yīng)變啦(具體實(shí)現(xiàn))；模板方法模式準(zhǔn)備一個(gè)抽象類，將部分邏輯以具體方法以及具體構(gòu)造子的形式實(shí)現(xiàn)，然后聲明一些抽象方法來(lái)迫使子類實(shí)現(xiàn)剩余的邏輯。不同的子類可以以不同的方式實(shí)現(xiàn)這些抽象方法，從而對(duì)剩余的邏輯有不同的實(shí)現(xiàn)。先制定一個(gè)頂級(jí)邏輯框架，而將邏輯的細(xì)節(jié)留給具體的子類去實(shí)現(xiàn)。1.3

21、.11. Visitor訪問(wèn)者模式情人節(jié)到了，要給每個(gè)MM送一束鮮花和一張卡片，可是每個(gè)MM送的花都要針對(duì)她個(gè)人的特點(diǎn)，每張卡片也要根據(jù)個(gè)人的特點(diǎn)來(lái)挑，我一個(gè)人哪搞得清楚，還是找花店老板和禮品店老板做一下Visitor，讓花店老板根據(jù)MM的特點(diǎn)選一束花，讓禮品店老板也根據(jù)每個(gè)人特點(diǎn)選一張卡，這樣就輕松多了；訪問(wèn)者模式的目的是封裝一些施加于某種數(shù)據(jù)結(jié)構(gòu)元素之上的操作。一旦這些操作需要修改的話，接受這個(gè)操作的數(shù)據(jù)結(jié)構(gòu)可以保持不變。訪問(wèn)者模式適用于數(shù)據(jù)結(jié)構(gòu)相對(duì)未定的系統(tǒng)，它把數(shù)據(jù)結(jié)構(gòu)和作用于結(jié)構(gòu)上的操作之間的耦合解脫開(kāi)，使得操作集合可以相對(duì)自由的演化。訪問(wèn)者模式使得增加新的操作變的很容易，就是增加一

22、個(gè)新的訪問(wèn)者類。訪問(wèn)者模式將有關(guān)的行為集中到一個(gè)訪問(wèn)者對(duì)象中，而不是分散到一個(gè)個(gè)的節(jié)點(diǎn)類中。當(dāng)使用訪問(wèn)者模式時(shí)，要將盡可能多的對(duì)象瀏覽邏輯放在訪問(wèn)者類中，而不是放到它的子類中。訪問(wèn)者模式可以跨過(guò)幾個(gè)類的等級(jí)結(jié)構(gòu)訪問(wèn)屬于不同的等級(jí)結(jié)構(gòu)的成員類。2. J2EE設(shè)計(jì)模式2.1. 表示層模式2.1.1. Intercepting Filter攔截過(guò)濾器模式ContextThe presentation-tier request handling mechanism receives many different types of requests, which require varied types

23、 of processing. Some requests are simply forwarded to the appropriate handler component, while other requests must be modified, audited, or uncompressed before being further processed.ProblemPreprocessing and post-processing of a client Web request and response are required.When a request enters a W

24、eb application, it often must pass several entrance tests prior to the main processing stage. For example,Has the client been authenticated? Does the client have a valid session? Is the client's IP address from a trusted network? Does the request path violate any constraints? What encoding does

25、the client use to send the data? Do we support the browser type of the client? Some of these checks are tests, resulting in a yes or no answer that determines whether processing will continue. Other checks manipulate the incoming data stream into a form suitable for processing.The classic solution c

26、onsists of a series of conditional checks, with any failed check aborting the request. Nested if/else statements are a standard strategy, but this solution leads to code fragility and a copy-and-paste style of programming, because the flow of the filtering and the action of the filters is compiled i

27、nto the application.The key to solving this problem in a flexible and unobtrusive manner is to have a simple mechanism for adding and removing processing components, in which each component completes a specific filtering action.ForcesCommon processing, such as checking the data-encoding scheme or lo

28、gging information about each request, completes per request. Centralization of common logic is desired. Services should be easy to add or remove unobtrusively without affecting existing components, so that they can be used in a variety of combinations, such as Logging and authentication Debugging an

29、d transformation of output for a specific client Uncompressing and converting encoding scheme of input SolutionCreate pluggable filters to process common services in a standard manner without requiring changes to core request processing code. The filters intercept incoming requests and outgoing resp

30、onses, allowing preprocessing and post-processing. We are able to add and remove these filters unobtrusively, without requiring changes to our existing code.We are able, in effect, to decorate our main processing with a variety of common services, such as security, logging, debugging, and so forth.

31、These filters are components that are independent of the main application code, and they may be added or removed declaratively. For example, a deployment configuration file may be modified to set up a chain of filters. The same configuration file might include a mapping of specific URLs to this filt

32、er chain. When a client requests a resource that matches this configured URL mapping, the filters in the chain are each processed in order before the requested target resource is invoked.2.1.2. Front Controller前端控制器模式ContextThe presentation-tier request handling mechanism must control and coordinate

33、 processing of each user across multiple requests. Such control mechanisms may be managed in either a centralized or decentralized manner.ProblemThe system requires a centralized access point for presentation-tier request handling to support the integration of system services, content retrieval, vie

34、w management, and navigation. When the user accesses the view directly without going through a centralized mechanism, two problems may occur:Each view is required to provide its own system services, often resulting in duplicate code. View navigation is left to the views. This may result in commingle

35、d view content and view navigation. Additionally, distributed control is more difficult to maintain, since changes will often need to be made in numerous places.ForcesCommon system services processing completes per request. For example, the security service completes authentication and authorization

36、 checks. Logic that is best handled in one central location is instead replicated within numerous views. Decision points exist with respect to the retrieval and manipulation of data. Multiple views are used to respond to similar business requests. A centralized point of contact for handling a reques

37、t may be useful, for example, to control and log a user's progress through the site. System services and view management logic are relatively sophisticated. SolutionUse a controller as the initial point of contact for handling a request. The controller manages the handling of the request, includ

38、ing invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies.The controller provides a centralized entry point that controls and manages

39、Web request handling. By centralizing decision points and controls, the controller also helps reduce the amount of Java code, called scriptlets, embedded in the JavaServer Pages (JSP) page.Centralizing control in the controller and reducing business logic in the view promotes code reuse across reque

40、sts. It is a preferable approach to the alternative-embedding code in multiple views-because that approach may lead to a more error-prone, reuse-by-copy- and-paste environment.Typically, a controller coordinates with a dispatcher component. Dispatchers are responsible for view management and navigat

41、ion. Thus, a dispatcher chooses the next view for the user and vectors control to the resource. Dispatchers may be encapsulated within the controller directly or can be extracted into a separate component.While the Front Controller pattern suggests centralizing the handling of all requests, it does

42、not limit the number of handlers in the system, as does a Singleton. An application may use multiple controllers in a system, each mapping to a set of distinct services.2.1.3. View Helper視圖助手模式ContextThe system creates presentation content, which requires processing of dynamic business data.ProblemP

43、resentation tier changes occur often and are difficult to develop and maintain when business data access logic and presentation formatting logic are interwoven. This makes the system less flexible, less reusable, and generally less resilient to change.Intermingling the business and systems logic wit

44、h the view processing reduces modularity and also provides a poor separation of roles among Web production and software development teams.ForcesBusiness data assimilation requirements are nontrivial. Embedding business logic in the view promotes a copy-and-paste type of reuse. This causes maintenanc

45、e problems and bugs because a piece of logic is reused in the same or different view by simply duplicating it in the new location. It is desirable to promote a clean separation of labor by having different individuals fulfill the roles of software developer and Web production team member. One view i

46、s commonly used to respond to a particular business request. SolutionA view contains formatting code, delegating its processing responsibilities to its helper classes, implemented as JavaBeans or custom tags. Helpers also store the view's intermediate data model and serve as business data adapte

47、rs.There are multiple strategies for implementing the view component. The JSP View Strategy suggests using a JSP as the view component. This is the preferred strategy, and it is the one most commonly used. The other principal strategy is the Servlet View Strategy, which utilizes a servlet as the vie

48、w (see the section "Strategies" for more information).Encapsulating business logic in a helper instead of a view makes our application more modular and facilitates component reuse. Multiple clients, such as controllers and views, may leverage the same helper to retrieve and adapt similar m

49、odel state for presentation in multiple ways. The only way to reuse logic embedded in a view is by copying and pasting it elsewhere. Furthermore, copy-and-paste duplication makes a system harder to maintain, since the same bug potentially needs to be corrected in multiple places.A signal that one ma

50、y need to apply this pattern to existing code is when scriptlet code dominates the JSP view. The overriding goal when applying this pattern, then, is the partitioning of business logic outside of the view. While some logic is best encapsulated within helper objects, other logic is better placed in a

51、 centralized component that sits in front of the views and the helpers-this might include logic that is common across multiple requests, such as authentication checks or logging services, for example. Refer to the "Intercepting Filter" on page 4 and "Front Controller" on page 21

52、for more information on these issues.If a separate controller is not employed in the architecture, or is not used to handle all requests, then the view component becomes the initial contact point for handling some requests. For certain requests, particularly those involving minimal processing, this

53、scenario works fine. Typically, this situation occurs for pages that are based on static information, such as the first of a set of pages that will be served to a user to gather some information (see "Dispatcher View" on page 232). Additionally, this scenario occurs in some cases when a me

54、chanism is employed to create composite pages (see "Composite View" on page 203).The View Helper pattern focuses on recommending ways to partition your application responsibilities. For related discussions about issues dealing with directing client requests directly to a view, please refer

55、 to the section "Dispatcher View" on page . Composite View復(fù)合視圖模式ContextSophisticated Web pages present content from numerous data sources, using multiple subviews that comprise a single display page. Additionally, a variety of individuals with different skill sets contribute to th

56、e development and maintenance of these Web pages.ProblemInstead of providing a mechanism to combine modular, atomic portions of a view into a composite whole, pages are built by embedding formatting code directly within each view.Modification to the layout of multiple views is difficult and error pr

57、one, due to the duplication of code.ForcesAtomic portions of view content change frequently. Multiple composite views use similar subviews, such as a customer inventory table. These atomic portions are decorated with different surrounding template text, or they appear in a different location within

58、the page. Layout changes are more difficult to manage and code harder to maintain when subviews are directly embedded and duplicated in multiple views. Embedding frequently changing portions of template text directly into views also potentially affects the availability and administration of the system. The server may need to be restarted before clients see the modifications or updates to these template components. SolutionUse composite views that are composed of multiple atomic subviews. Each component of the template may be included dynamical