JAVA設計模式總結

JAVA設計模式總結之23種設計模式

文檔修訂摘要日期修訂號描述著者審閱者2020-03-27序列號1完成初稿張海濱目錄TOC\o"1-5"\h\zJAVA設計模式總結之23種設計模式1\o"CurrentDocument"概述4\o"CurrentDocument"概念4\o"CurrentDocument"設計模式的三個分類4\o"CurrentDocument"各分類種模式的關鍵點5\o"CurrentDocument"來源網(wǎng)站6\o"CurrentDocument"23種設計模式66..\o"CurrentDocument"單例模式6\o"CurrentDocument"工廠方法模式7\o"CurrentDocument"抽象工廠模式8建造者模式9\o"CurrentDocument"原型模式10\o"CurrentDocument"適配器模式11\o"CurrentDocument"橋接模式11\o"CurrentDocument"組合模式12\o"CurrentDocument"裝飾模式13\o"CurrentDocument"外觀模式14\o"CurrentDocument"亨元模式15\o"CurrentDocument"代理模式16\o"CurrentDocument"訪問者模式17\o"CurrentDocument"模板模式18\o"CurrentDocument"策略模式19\o"CurrentDocument"狀態(tài)模式20\o"CurrentDocument"觀察者模式20\o"CurrentDocument"備忘錄模式21\o"CurrentDocument"中介者模式22\o"CurrentDocument"迭代器模式22\o"CurrentDocument"解釋器模式23\o"CurrentDocument"命令模式24\o"CurrentDocument"責任鏈模式25\o"CurrentDocument"學習設計模式的三種境界261.概述概念設計模式(Designpattern)是一套被反復使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設計經(jīng)驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。毫無疑問，設計模式于己于他人于系統(tǒng)都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理的運用設計模式可以完美的解決很多問題，每種模式在現(xiàn)在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重復發(fā)生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。簡單說：模式：在某些場景下，針對某類問題的某種通用的解決方案。場景：項目所在的環(huán)境問題：約束條件，項目目標等解決方案：通用、可復用的設計，解決約束達到目標。設計模式的三個分類創(chuàng)建型模式：對象實例化的模式，創(chuàng)建型模式用于解耦對象的實例化過程。結構型模式：把類或對象結合在一起形成一個更大的結構。行為型模式：類和對象如何交互，及劃分責任和算法。如下圖所示：

訪間者■?式模梅模式策略棋式狀態(tài)模式觀索者模H備忘錄根式中介者喉式迭代器模式景經(jīng)器樨式專耳■模式責汪特模式單例模式各分類種模式的關鍵點單例模式：某個類只能有一個實例，提供一個全局的訪問點。單例模式簡單工廠：一個工廠類根據(jù)傳入的參量決定創(chuàng)建出那一種產(chǎn)品類的實例。工廠方法：定義一個創(chuàng)建對象的接口，讓子類決定實例化那個類。抽象工廠：創(chuàng)建相關或依賴對象的家族，而無需明確指定具體類。建造者模式：封裝一個復雜對象的構建過程，并可以按步驟構造。原型模式：通過復制現(xiàn)有的實例來創(chuàng)建新的實例。適配器模式：將一個類的方法接口轉換成客戶希望的另外一個接口。組合模式：將對象組合成樹形結構以表示'、”部分-整體'、”的層次結構。裝飾模式：動態(tài)的給對象添加新的功能。代理模式：為其他對象提供一個代理以便控制這個對象的訪問。亨元（蠅量）模式：通過共享技術來有效的支持大量細粒度的對象。外觀模式：對外提供一個統(tǒng)一的方法，來訪問子系統(tǒng)中的一群接口。橋接模式：將抽象部分和它的實現(xiàn)部分分離，使它們都可以獨立的變化。模板模式：定義一個算法結構，而將一些步驟延遲到子類實現(xiàn)。解釋器模式：給定一個語言，定義它的文法的一種表示，并定義一個解釋器。策略模式：定義一系列算法，把他們封裝起來，并且使它們可以相互替換。狀態(tài)模式：允許一個對象在其對象內(nèi)部狀態(tài)改變時改變它的行為。觀察者模式：對象間的一對多的依賴關系。備忘錄模式：在不破壞封裝的前提下，保持對象的內(nèi)部狀態(tài)。中介者模式：用一個中介對象來封裝一系列的對象交互。命令模式：將命令請求封裝為一個對象，使得可以用不同的請求來進行參數(shù)化。訪問者模式：在不改變數(shù)據(jù)結構的前提下，增加作用于一組對象元素的新功能。責任鏈模式：將請求的發(fā)送者和接收者解耦，使的多個對象都有處理這個請求的機會。迭代器模式：一種遍歷訪問聚合對象中各個元素的方法，不暴露該對象的內(nèi)部結構。來源網(wǎng)站來源網(wǎng)站2.23種設計模式單例模式單例模式，它的定義就是確保某一個類只有一個實例，并且提供一個全局訪問點。單例模式具備典型的3個特點：1、只有一個實例。2、自我實例化。3、提供全局訪問點。因此當系統(tǒng)中只需要一個實例對象或者系統(tǒng)中只允許一個公共訪問點，除了這個公共訪問點外，不能通過其他訪問點訪問該實例時，可以使用單例模式。單例模式的主要優(yōu)點就是節(jié)約系統(tǒng)資源、提高了系統(tǒng)效率，同時也能夠嚴格控制客戶對它的訪問。也許就是因為系統(tǒng)中只有一個實例，這樣就導致了單例類的職責過重，違背了''單一職責原則''，同時也沒有抽象類，所以擴展起來有一定的困難。其UML結構圖非常簡單，就只有一個類，如下圖：工廠方法模式作為抽象工廠模式的攣生兄弟，工廠方法模式定義了一個創(chuàng)建對象的接口，但由子類決定要實例化的類是哪一個，也就是說工廠方法模式讓實例化推遲到子類。工廠方法模式非常符合''開閉原則”，當需要增加一個新的產(chǎn)品時，我們只需要增加一個具體的產(chǎn)品類和與之對應的具體工廠即可，無須修改原有系統(tǒng)。同時在工廠方法模式中用戶只需要知道生產(chǎn)產(chǎn)品的具體工廠即可，無須關系產(chǎn)品的創(chuàng)建過程，甚至連具體的產(chǎn)品類名稱都不需要知道。雖然他很好的符合了''開閉原則”，但是由于每新增一個新產(chǎn)品時就需要增加兩個類，這樣勢必會導致系統(tǒng)的復雜度增加。其UML結構圖：抽象工廠模式所謂抽象工廠模式就是提供一個接口，用于創(chuàng)建相關或者依賴對象的家族，而不需要明確指定具體類。他允許客戶端使用抽象的接口來創(chuàng)建一組相關的產(chǎn)品，而不需要關系實際產(chǎn)出的具體產(chǎn)品是什么。這樣一來，客戶就可以從具體的產(chǎn)品中被解耦。它的優(yōu)點是隔離了具體類的生成，使得客戶端不需要知道什么被創(chuàng)建了，而缺點就在于新增新的行為會比較麻煩，因為當添加一個新的產(chǎn)品對象時，需要更加需要更改接口及其下所有子類。其UML結構圖如下：

2.4.建造者模式對于建造者模式而已，它主要是將一個復雜對象的構建與表示分離，使得同樣的構建過程可以創(chuàng)建不同的表示。適用于那些產(chǎn)品對象的內(nèi)部結構比較復雜。2.4.建造者模式建造者模式將復雜產(chǎn)品的構建過程封裝分解在不同的方法中，使得創(chuàng)建過程非常清晰，能夠讓我們更加精確的控制復雜產(chǎn)品對象的創(chuàng)建過程，同時它隔離了復雜產(chǎn)品對象的創(chuàng)建和使用，使得相同的創(chuàng)建過程能夠創(chuàng)建不同的產(chǎn)品。但是如果某個產(chǎn)品的內(nèi)部結構過于復雜，將會導致整個系統(tǒng)變得非常龐大，不利于控制，同時若幾個產(chǎn)品之間存在較大的差異，則不適用建造者模式，畢竟這個世界上存在相同點大的兩個產(chǎn)品并不是很多，所以它的使用范圍有限。其UML結構圖：原型模式在我們應用程序可能有某些對象的結構比較復雜，但是我們又需要頻繁的使用它們，如果這個時候我們來不斷的新建這個對象勢必會大大損耗系統(tǒng)內(nèi)存的，這個時候我們需要使用原型模式來對這個結構復雜又要頻繁使用的對象進行克隆。所以原型模式就是用原型實例指定創(chuàng)建對象的種類，并且通過復制這些原型創(chuàng)建新的對象。它主要應用與那些創(chuàng)建新對象的成本過大時。它的主要優(yōu)點就是簡化了新對象的創(chuàng)建過程，提高了效率，同時原型模式提供了簡化的創(chuàng)建結構。UML結構圖：模式結構原型模式包含如下角色：Prototype：抽象原型類ConcretePrototype:具體原型類Client：客戶類適配器模式在我們的應用程序中我們可能需要將兩個不同接口的類來進行通信，在不修改這兩個的前提下我們可能會需要某個中間件來完成這個銜接的過程。這個中間件就是適配器。所謂適配器模式就是將一個類的接口，轉換成客戶期望的另一個接口。它可以讓原本兩個不兼容的接口能夠無縫完成對接。作為中間件的適配器將目標類和適配者解耦，增加了類的透明性和可復用性。Adaptee+5peoficRft4uestO版gp映-RequestflClient作為中間件的適配器將目標類和適配者解耦，增加了類的透明性和可復用性。Adaptee+5peoficRft4uestO版gp映-RequestflClientTarget：目標抽象類Adapter:適配器類Adaptee：適配者類Client：客戶類橋接模式如果說某個系統(tǒng)能夠從多個角度來進行分類，且每一種分類都可能會變化，那么我們需要做的就是講這多個角度分離出來，使得他們能獨立變化，減少他們之間的耦合，這個分離過程就使用了橋接模式。所謂橋接模式就是講抽象部分和實現(xiàn)部分隔離開來，使得他們能夠獨立變化。

組合模式組合模式組合多個對象形成樹形結構以表示''整體-部分''的結構層次。它定義了如何將容器對象和葉子對象進行遞歸組合，使得客戶在使用的過程中無須進行區(qū)分，可以對他們進行一致的處理。在使用組合模式中需要注意一點也是組合模式最關鍵的地方：葉子對象和組合對象實現(xiàn)相同的接口。這就是組合模式能夠將葉子節(jié)點和對象節(jié)點進行一致處理的原因。雖然組合模式能夠清晰地定義分層次的復雜對象，也使得增加新構件也更容易，但是這樣就導致了系統(tǒng)的設計變得更加抽象，如果系統(tǒng)的業(yè)務規(guī)則比較復雜的話，使用組合模式就有一定的挑戰(zhàn)了。模式結構組合模式包含如下角色：Component:抽象構件Leaf:葉子構件Composite:容器構件Client:客戶類裝飾模式我們可以通過繼承和組合的方式來給一個對象添加行為，雖然使用繼承能夠很好擁有父類的行為，但是它存在幾個缺陷：一、對象之間的關系復雜的話，系統(tǒng)變得復雜不利于維護。二、容易產(chǎn)生''類爆炸''現(xiàn)象。三、是靜態(tài)的。在這里我們可以通過使用裝飾者模式來解決這個問題。裝飾者模式，動態(tài)地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更加有彈性的替代方案。雖然裝飾者模式能夠動態(tài)將責任附加到對象上，但是他會產(chǎn)生許多的細小對象，增加了系統(tǒng)的復雜度。模式結構裝飾模式包含如下角色：Component:抽象構件ConcreteComponent:具體構件Decorator:抽象裝飾類ConcreteDecorator:具體裝飾類外觀模式我們都知道類與類之間的耦合越低，那么可復用性就越好，如果兩個類不必彼此通信，那么就不要讓這兩個類發(fā)生直接的相互關系，如果需要調用里面的方法，可以通過第三者來轉發(fā)調用。外觀模式非常好的詮釋了這段話。外觀模式提供了一個統(tǒng)一的接口，用來訪問子系統(tǒng)中的一群接口。它讓一個應用程序中子系統(tǒng)間的相互依賴關系減少到了最少，它給子系統(tǒng)提供了一個簡單、單一的屏障，客戶通過這個屏障來與子系統(tǒng)進行通信。通過使用外觀模式，使得客戶對子系統(tǒng)的引用變得簡單了，實現(xiàn)了客戶與子系統(tǒng)之間的松耦合。但是它違背了''開閉原則”，因為增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼。外觀模式包含如下角色：Facade:外觀角色SubSystem:子系統(tǒng)角色亨元模式在一個系統(tǒng)中對象會使得內(nèi)存占用過多，特別是那些大量重復的對象，這就是對系統(tǒng)資源的極大浪費。享元模式對對象的重用提供了一種解決方案，它使用共享技術對相同或者相似對象實現(xiàn)重用。享元模式就是運行共享技術有效地支持大量細粒度對象的復用。系統(tǒng)使用少量對象，而且這些都比較相似，狀態(tài)變化小，可以實現(xiàn)對象的多次復用。這里有一點要注意：享元模式要求能夠共享的對象必須是細粒度對象。享元模式通過共享技術使得系統(tǒng)中的對象個數(shù)大大減少了，同時享元模式使用了內(nèi)部狀態(tài)和外部狀態(tài)，同時外部狀態(tài)相對獨立，不會影響到內(nèi)部狀態(tài)，所以享元模式能夠使得享元對象在不同的環(huán)境下被共享。同時正是分為了內(nèi)部狀態(tài)和外部狀態(tài)，享元模式會使得系統(tǒng)變得更加復雜，同時也會導致讀取外部狀態(tài)所消耗的時間過長。享元模式包含如下角色：Flyweight:抽象享元類ConcreteFlyweight:具體享元類UnsharedConcreteFlyweight:非共享具體享元類FlyweightFactory:享元工廠類代理模式代理模式就是給一個對象提供一個代理，并由代理對象控制對原對象的引用。它使得客戶不能直接與真正的目標對象通信。代理對象是目標對象的代表，其他需要與這個目標對象打交道的操作都是和這個代理對象在交涉。代理對象可以在客戶端和目標對象之間起到中介的作用，這樣起到了的作用和保護了目標對象的，同時也在一定程度上面減少了系統(tǒng)的耦合度。Subject

+RequestOA代理模式包含如下角色：Subject:抽象主題角色Proxy:代理主題角色RealSubject:真實主題角色訪問者模式訪問者模式俗稱23大設計模式中最難的一個。除了結構復雜外，理解也比較難。在我們軟件開發(fā)中我們可能會對同一個對象有不同的處理，如果我們都做分別的處理，將會產(chǎn)生災難性的錯誤。對于這種問題，訪問者模式提供了比較好的解決方案。訪問者模式即表示一個作用于某對象結構中的各元素的操作，它使我們可以在不改變各元素的類的前提下定義作用于這些元素的新操作。訪問者模式的目的是封裝一些施加于某種數(shù)據(jù)結構元素之上的操作，一旦這些操作需要修改的話，接受這個操作的數(shù)據(jù)結構可以保持不變。為不同類型的元素提供多種訪問操作方式，且可以在不修改原有系統(tǒng)的情況下增加新的操作方式。同時我們還需要明確一點那就是訪問者模式是適用于那些數(shù)據(jù)結構比較穩(wěn)定的，因為他是將數(shù)據(jù)的操作與數(shù)據(jù)結構進行分離了，如果某個系統(tǒng)的數(shù)據(jù)結構相對穩(wěn)定，但是操作算法易于變化的話，就比較適用適用訪問者模式，因為訪問者模式使得算法操作的增加變得比較簡單了。訪問者模式包含如下角色：Vistor:抽象訪問者ConcreteVisitor:具體訪問者Element:抽象元素ConcreteElement:具體元素Objectstructure:對象結構模板模式有些時候我們做某幾件事情的步驟都差不多，僅有那么一小點的不同，在軟件開發(fā)的世界里同樣如此，如果我們都將這些步驟都一一做的話，費時費力不討好。所以我們可以將這些步驟分解、封裝起來，然后利用繼承的方式來繼承即可，當然不同的可以自己重寫實現(xiàn)嘛！這就是模板方法模式提供的解決方案。所謂模板方法模式就是在一個方法中定義一個算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以在不改變算法結構的情況下，重新定義算法中的某些步驟。模板方法模式就是基于繼承的代碼復用技術的。在模板方法模式中，我們可以將相同部分的代碼放在父類中，而將不同的代碼放入不同的子類中。也就是說我們需要聲明一個抽象的父類，將部分邏輯以具體方法以及具體構造函數(shù)的形式實現(xiàn)，然后聲明一些抽象方法讓子類來實現(xiàn)剩余的邏輯，不同的子類可以以不同的方式來實現(xiàn)這些邏輯。所以模板方法的模板其實就是一個普通的方法，只不過這個方法是將算法實現(xiàn)的步驟封裝起來的。模板方法模式包含如下角色:Abstractclass:抽象類ConcreteClass:具體子類策略模式我們知道一件事可能會有很多種方式來實現(xiàn)它，但是其中總有一種最高效的方式，在軟件開發(fā)的世界里面同樣如此，我們也有很多中方法來實現(xiàn)一個功能，但是我們需要一種簡單、高效的方式來實現(xiàn)它，使得系統(tǒng)能夠非常靈活，這就是策略模式。所以策略模式就是定義了算法族，分別封裝起來，讓他們之前可以互相轉換，此模式然該算法的變化獨立于使用算法的客戶。在策略模式中它將這些解決問題的方法定義成一個算法群，每一個方法都對應著一個具體的算法，這里的一個算法我就稱之為一個策略。雖然策略模式定義了算法，但是它并不提供算法的選擇，即什么算法對于什么問題最合適這是策略模式所不關心的，所以對于策略的選擇還是要客戶端來做?？蛻舯仨氁宄闹烂總€算法之間的區(qū)別和在什么時候什么地方使用什么策略是最合適的，這樣就增加客戶端的負擔。同時策略模式也非常完美的符合了''開閉原則”，用戶可以在不修改原有系統(tǒng)的基礎上選擇算法或行為，也可以靈活地增加新的算法或行為。但是一個策略對應一個類將會是系統(tǒng)產(chǎn)生很多的策略類。策略模式包含如下角色：Context:環(huán)境類Strategy:抽象策略類ConcreteStrategy:具體策略類狀態(tài)模式在很多情況下我們對象的行為依賴于它的一個或者多個變化的屬性，這些可變的屬性我們稱之為狀態(tài)，也就是說行為依賴狀態(tài)，即當該對象因為在外部的互動而導致他的狀態(tài)發(fā)生變化，從而它的行為也會做出相應的變化。對于這種情況，我們是不能用行為來控制狀態(tài)的變化，而應該站在狀態(tài)的角度來思考行為，即是什么狀態(tài)就要做出什么樣的行為。這個就是狀態(tài)模式。所以狀態(tài)模式就是允許對象在內(nèi)部狀態(tài)發(fā)生改變時改變它的行為，對象看起來好像修改了它的類。在狀態(tài)模式中我們可以減少大塊的if...else語句，它是允許態(tài)轉換邏輯與狀態(tài)對象合成一體，但是減少if^else語句的代價就是會換來大量的類，所以狀態(tài)模式勢必會增加系統(tǒng)中類或者對象的個數(shù)。同時狀態(tài)模式是將所有與某個狀態(tài)有關的行為放到一個類中，并且可以方便地增加新的狀態(tài)，只需要改變對象狀態(tài)即可改變對象的行為。但是這樣就會導致系統(tǒng)的結構和實現(xiàn)都會比較復雜，如果使用不當就會導致程序的結構和代碼混亂，不利于維護。狀態(tài)模式包含如下角色：Context:環(huán)境類State:抽象狀態(tài)類ConcreteState:具體狀態(tài)類觀察者模式何謂觀察者模式？觀察者模式定義了對象之間的一對多依賴關系，這樣一來，當一個對象改變狀態(tài)時，它的所有依賴者都會收到通知并且自動更新。在這里，發(fā)生改變的對象稱之為觀察目標，而被通知的對象稱之為觀察者。一個觀察目標可以對應多個觀察者，而且這些觀察者之間沒有相互聯(lián)系，所以么可以根據(jù)需要增加和刪除觀察者，使得系統(tǒng)更易于擴展。所以觀察者提供了一種對象設計，讓主題和觀察者之間以松耦合的方式結合。觀察者模式包含如下角色：Subject:目標ConcreteSubject:具體目標Observer:觀察者ConcreteObserver:具體觀察者備忘錄模式后悔藥人人都想要，但是事實卻是殘酷的，根本就沒有后悔藥可買，但是也不僅如此，在軟件的世界里就有后悔藥！備忘錄模式就是一種后悔藥，它給我們的軟件提供后悔藥的機制，通過它可以使系統(tǒng)恢復到某一特定的歷史狀態(tài)。所謂備忘錄模式就是在不破壞封裝的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)，這樣可以在以后將對象恢復到原先保存的狀態(tài)。它實現(xiàn)了對信息的封裝，使得客戶不需要關心狀態(tài)保存的細節(jié)。保存就要消耗資源，所以備忘錄模式的缺點就在于消耗資源。如果類的成員變量過多，勢必會占用比較大的資源，而且每一次保存都會消耗一定的內(nèi)存。備忘錄模式包含如下角色：Originator:原發(fā)器Memento:備忘錄Caretaker:負責人中介者模式租房各位都有過的經(jīng)歷吧！在這個過程中中介結構扮演著很重要的角色，它在這里起到一個中間者的作用，給我們和房主互相傳遞信息。在外面軟件的世界里同樣需要這樣一個中間者。在我們的系統(tǒng)中有時候會存在著對象與對象之間存在著很強、復雜的關聯(lián)關系，如果讓他們之間有直接的聯(lián)系的話，必定會導致整個系統(tǒng)變得非常復雜，而且可擴展性很差！在前面我們就知道如果兩個類之間沒有不必彼此通信，我們就不應該讓他們有直接的關聯(lián)關系，如果實在是需要通信的話，我們可以通過第三者來轉發(fā)他們的請求。同樣，這里我們利用中介者來解決這個問題。所謂中介者模式就是用一個中介對象來封裝一系列的對象交互，中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。在中介者模式中，中介對象用來封裝對象之間的關系，各個對象可以不需要知道具體的信息通過中介者對象就可以實現(xiàn)相互通信。它減少了對象之間的互相關系，提供了系統(tǒng)可復用性，簡化了系統(tǒng)的結構。在中介者模式中，各個對象不需要互相知道了解，他們只需要知道中介者對象即可，但是中介者對象就必須要知道所有的對象和他們之間的關聯(lián)關系，正是因為這樣就導致了中介者對象的結構過于復雜，承擔了過多的職責，同時它也是整個系統(tǒng)的核心所在，它有問題將會導致整個系統(tǒng)的問題。所以如果在系統(tǒng)的設計過程中如果出現(xiàn)''多對多''的復雜關系群時，千萬別急著使用中介者模式，而是要仔細思考是不是您設計的系統(tǒng)存在問題。Mediator:抽象中介者ConcreteMediator:具體中介者Colleague:抽象同事類ConcreteColleague:具體同事類迭代器模式對于迭代在編程過程中我們經(jīng)常用到，能夠游走于聚合內(nèi)的每一個元素，同時還可以提供多種不同的遍歷方式，這就是迭代器模式的設計動機。在我們實際的開發(fā)過程中，我們可能會需要根據(jù)不同的需求以不同的方式來遍歷整個對象，但是我們又不希望在聚合對象的抽象接口中充斥著各種不同的遍歷操作，于是我們就希望有某個東西能夠以多種不同的方式來遍歷一個聚合對象，這時迭代器模式出現(xiàn)了。何為迭代器模式？所謂迭代器模式就是提供一種方法順序訪問一個聚合對象中的各個元素，而不是暴露其內(nèi)部的表示。迭代器模式是將迭代元素的責任交給迭代器，而不是聚合對象，我們甚至在不需要知道該聚合對象的內(nèi)部結構就可以實現(xiàn)該聚合對象的迭代。通過迭代器模式，使得聚合對象的結構更加簡單，它不需要關注它元素的遍歷，只需要專注它應該專注的事情，這樣就更加符合單一職責原則了。迭代器模式包含如下角色：Iterator:抽象迭代器Concreteiterator:具體迭代器Aggregate:抽象聚合類ConcreteAggregate:具體聚合類解釋器模式所謂解釋器模式就是定義語言的文法，并且建立一個解釋器來解釋該語言中的