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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22、個新的訪問者類。訪問者模式將有關(guān)的行為集中到一個訪問者對象中，而不是分散到一個個的節(jié)點類中。當使用訪問者模式時，要將盡可能多的對象瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結(jié)構(gòu)訪問屬于不同的等級結(jié)構(gòu)的成員類。2. J2EE設(shè)計模式2.1. 表示層模式2.1.1. Intercepting Filter攔截過濾器模式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 clients IP address from a trusted network? Does the request path violate any constraints? What encoding does the c

25、lient 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 consis

26、ts 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 into t

27、he 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 logging

28、 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 and tra

29、nsformation 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 responses

30、, 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. These

31、 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 filter ch

32、ain. 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 proc

33、essing 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, view man

34、agement, 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 commingled vie

35、w 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 chec

36、ks. 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 request may

37、 be useful, for example, to control and log a users 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, including invoki

38、ng 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 Web reques

39、t 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 requests. It is

40、 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 navigation. Thus,

41、 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 not limit

42、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.ProblemPresentatio

43、n 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 with the view

44、 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 maintenance problems

45、 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 is commonly

46、 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 views intermediate data model and serve as business data adapters.There are mu

47、ltiple 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 view (see the sect

48、ion 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 model state for presentation

49、 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 may need to apply this patter

50、n 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 centralized component that

51、 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 for more information on these issues.If a separate

52、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 scenario works fine. Typically, this situation occu

53、rs 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 mechanism is employed to create composite pages (see Composite Vi

54、ew 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 to the section Dispatcher View on page . Composite View復合視圖模式Cont

55、extSophisticated 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 the development and maintenance of these Web pages.ProblemInstead of providing a mechanis

56、m 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 prone, due to the duplication of code.ForcesAtomic portions of view content change freque

57、ntly. 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 the page. Layout changes are more difficult to manage and code harder to maintain when

58、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 dynamically into th