Java設(shè)計模式

1、Java設(shè)計模式金惠玉Java設(shè)計模式p創(chuàng)建模式p結(jié)構(gòu)模式p行為模式軟件設(shè)計模式基礎(chǔ)p什么是設(shè)計模式廣義講，軟件設(shè)計模式是可解決一類軟件問題并能重復(fù)使用的軟件設(shè)計方案狹義講，設(shè)計模式是對被用來在特定場景下解決一般設(shè)計問題的類和相互通信的對象的描述。是在類和對象的層次描述的可重復(fù)使用的軟件設(shè)計問題的解決方案模式體現(xiàn)的是程序整體的構(gòu)思，所以有時候它也會出現(xiàn)在分析或者是概要設(shè)計階段 模式的核心思想是通過增加抽象層，把變化部分從那些不變部分里分離出來軟件設(shè)計模式基礎(chǔ)p模式的基本要素模式的基本要素模式名稱模式名稱(Pattern Name)(Pattern Name)問題問題(Problem)(Prob

2、lem)：描述應(yīng)該在何時使用模式。解釋了設(shè)計問題和問題存在的前因后果,可能還描述模式必須滿足的先決條件解決方案解決方案(Solution)(Solution)：描述了設(shè)計的組成成分、相互關(guān)系及各自的職責(zé)和協(xié)作方式。模式就像一個模板，可應(yīng)用于多種場合，所以解決方案并不描述一個具體的設(shè)計或?qū)崿F(xiàn)，而是提供設(shè)計問題的抽象描述和解決問題所采用的元素組合（類和對象）效果效果(consequences )(consequences )：描述模式的應(yīng)用效果及使用模式應(yīng)權(quán)衡的問題軟件設(shè)計模式基礎(chǔ)p如何描述設(shè)計模式如何描述設(shè)計模式u模式名和分類模式名和分類：模式名簡介的描述了模式的本質(zhì)。u意圖意圖：設(shè)計模式是做什

3、么的？它的基本原理和意圖是什么？它解決的是什么樣的特定設(shè)計問題？u別名別名：模式的其他名稱u動機動機：說明一個設(shè)計問題以及如何用模式中的類、對象來解決該問題的特定情景u適用性適用性：什么情況下可以使用該設(shè)計模式？該模式可用來改進(jìn)哪些不良設(shè)計？如何識別這些情況？u結(jié)構(gòu)結(jié)構(gòu)：采用對象建模技術(shù)對模式中的類進(jìn)行圖形描述u參與者參與者：指設(shè)計模式中的類和(或)對象以及它們各自的職責(zé)軟件設(shè)計模式基礎(chǔ)p如何描述設(shè)計模式如何描述設(shè)計模式u協(xié)作協(xié)作：模式的參與者如何協(xié)作以實現(xiàn)其職責(zé)u效果效果：模式如何支持其目標(biāo)？使用模式的效果和所需做的權(quán)衡取舍？系統(tǒng)結(jié)構(gòu)的哪些方面可以獨立改變？u實現(xiàn)實現(xiàn)：實現(xiàn)模式時需了解的一些

4、提示、技術(shù)要點及應(yīng)避免的缺陷，以及是否存在某些特定于實現(xiàn)語言的問題u代碼示例代碼示例：用來說明怎樣實現(xiàn)該模式的代碼片段u已知應(yīng)用已知應(yīng)用：實際系統(tǒng)中發(fā)現(xiàn)的模式的例子u相關(guān)模式相關(guān)模式：與這個模式緊密相關(guān)的模式有哪些？其不同之處是什么？這個模式應(yīng)與哪些其他模式一起使用？面向?qū)ο笤O(shè)計原則面向?qū)ο笤O(shè)計原則面向?qū)ο笤O(shè)計原則p單一職責(zé)原則（SRP，Single Responsibility Principle）p開放封閉原則（OCP，Open Closed Principle）p依賴倒轉(zhuǎn)原則（DIP，Dependence Inversion Principle）p接口隔離原則（ISP，Interface

5、 Segregation Principle）p里氏代換原則（LSP，Liskov Substitution Principle）面向?qū)ο笤O(shè)計原則p單一職責(zé)原則（SRP） 對于單一職責(zé)原則，其核心思想為：一個類，最好只做一件事，只有一個引起它的變化。單一職責(zé)原則可以看做是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申，將職責(zé)定義為引起變化的原因，以提高內(nèi)聚性來減少引起變化的原因。職責(zé)過多，可能引起它變化的原因就越多，這將導(dǎo)致職責(zé)依賴，相互之間就產(chǎn)生影響，從而大大損傷其內(nèi)聚性和耦合度。通常意義下的單一職責(zé)，就是指只有一種單一功能，不要為類實現(xiàn)過多的功能點，以保證實體只有一個引起它變化的原因。專注，是一個人

6、優(yōu)良的品質(zhì)；同樣的，單一也是一個類的優(yōu)良設(shè)計。交雜不清的職責(zé)將使得代碼看起來特別別扭牽一發(fā)而動全身，有失美感和必然導(dǎo)致丑陋的系統(tǒng)錯誤風(fēng)險。面向?qū)ο笤O(shè)計原則p開放封閉原則（OCP） 開放封閉原則是面向?qū)ο笏性瓌t的核心，軟件設(shè)計追求的目標(biāo)就是封裝變化、降低耦合，而開放封閉原則就是這一目標(biāo)的最直接體現(xiàn)。 開放封閉原則，其核心思想是：軟件實體應(yīng)該是可擴展的，而不可修改軟件實體應(yīng)該是可擴展的，而不可修改的。也就是，對擴展開放，對修改封閉的。的。也就是，對擴展開放，對修改封閉的。因此，開放封閉原則主要體現(xiàn)在兩個方面：對擴展開放，意味著有新的需求或變化時，可以對現(xiàn)有代碼進(jìn)行擴展，以適應(yīng)新的情況對修改封閉，

7、意味著類一旦設(shè)計完成，就可以獨立完成其工作，而不要對其進(jìn)行任何嘗試的修改。 實現(xiàn)開放封閉原則的核心思想就是對抽象編程，而不對具體編程，因為抽象相對穩(wěn)定。讓類依賴于固定的抽象，所以修改就是封閉的；而通過面向?qū)ο蟮睦^承和多態(tài)機制，又可以實現(xiàn)對抽象類的繼承，通過覆寫其方法來改變固有行為，實現(xiàn)新的拓展方法，所以就是開放的。1. “需求總是變化”沒有不變的軟件，所以就需要用封閉開放原則來封閉變化滿足需求，同時還能保持軟件內(nèi)部的封裝體系穩(wěn)定，不被需求的變化影響。面向?qū)ο笤O(shè)計原則p依賴倒轉(zhuǎn)原則（DIP） 依賴倒置原則其核心思想是：依賴于抽象。具體而言就是高層模塊不依賴于底層模塊，二者都同依賴于抽象；抽象不依

8、賴于具體，具體依賴于抽象。 依賴一定會存在于類與類、模塊與模塊之間。當(dāng)兩個模塊之間存在緊密的耦合關(guān)系時，最好的方法就是分離接口和實現(xiàn)：在依賴之間定義一個抽象的接口使得高層模塊調(diào)用接口，而底層模塊實現(xiàn)接口的定義，以此來有效控制耦合關(guān)系，達(dá)到依賴于抽象的設(shè)計目標(biāo)。 抽象的穩(wěn)定性決定了系統(tǒng)的穩(wěn)定性，因為抽象是不變的，依賴于抽象是面向?qū)ο笤O(shè)計的精髓，也是依賴倒置原則的核心。 依賴于抽象是一個通用的原則，而某些時候依賴于細(xì)節(jié)則是在所難免的，必須權(quán)衡在抽象和具體之間的取舍，方法不是一層不變的。依賴于抽象，就是對接口編程，不要對實現(xiàn)編程。面向?qū)ο笤O(shè)計原則p接口隔離原則（ISP） 對于接口隔離原則，其核心思想

9、是：使用多個小的專門的接口，而不要使用一個大的總接口。具體而言，接口隔離原則體現(xiàn)在：接口應(yīng)該是內(nèi)聚的，應(yīng)該避免“胖”接口。一個類對另外一個類的依賴應(yīng)該建立在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。 接口有效地將細(xì)節(jié)和抽象隔離，體現(xiàn)了對抽象編程的一切好處，接口隔離強調(diào)接口的單一性。而胖接口存在明顯的弊端，會導(dǎo)致實現(xiàn)的類型必須完全實現(xiàn)接口的所有方法、屬性等；而某些時候，實現(xiàn)類型并非需要所有的接口定義，在設(shè)計上這是“浪費”，而且在實施上這會帶來潛在的問題，對胖接口的修改將導(dǎo)致一連串的客戶端程序需要修改，有時候這是一種災(zāi)難。在這種情況下，將胖接口分解為多個特點的定制化方法，使得客戶端僅

10、僅依賴于它們的實際調(diào)用的方法，從而解除了客戶端不會依賴于它們不用的方法。 分離的手段主要有以下兩種：1、委托分離，通過增加一個新的類型來委托客戶的請求，隔離客戶和接口的直接依賴，但是會增加系統(tǒng)的開銷。2、多重繼承分離，通過接口多繼承來實現(xiàn)客戶的需求，這種方式是較好的。面向?qū)ο笤O(shè)計原則p里氏代換原則（LSP） 里氏替換原則核心思想是：子類必須能夠替換其基類子類必須能夠替換其基類。這一思想體現(xiàn)為對繼承機制的約束規(guī)范，只有子類能夠替換基類時，才能保證系統(tǒng)在運行期內(nèi)識別子類，這是保證繼承復(fù)用的基礎(chǔ)。在父類和子類的具體行為中，必須嚴(yán)格把握繼承層次中的關(guān)系和特征，將基類替換為子類，程序的行為不會發(fā)生任何變

11、化。同時，這一約束反過來則是不成立的，子類可以替換基類，但是基類不一定能替換子類。 里氏替換原則，主要著眼于對抽象和多態(tài)建立在繼承的基礎(chǔ)上，因此只有遵循了里氏替換原則，才能保證繼承復(fù)用是可靠地。實現(xiàn)的方法是面向接口編程面向接口編程：將公共部分抽象為基類接口或抽象類，在子類中通過覆寫父類的方法實現(xiàn)新的方式支持同樣的職責(zé)。 里氏替換原則是關(guān)于繼承機制的設(shè)計原則，違反了里氏替換原則就必然導(dǎo)致違反開放封閉原則。 里氏替換原則能夠保證系統(tǒng)具有良好的拓展性，同時實現(xiàn)基于多態(tài)的抽象機制，能夠減少代碼冗余，避免運行期的類型判別。設(shè)計模式設(shè)計模式Java設(shè)計模式-創(chuàng)建模式p創(chuàng)建模式工廠模式（Factory）原型

12、模式（Prototype）生成器模式（Builder）單態(tài)模式（Singleton）Java設(shè)計模式-創(chuàng)建模式p創(chuàng)建模式-工廠模式（Factory）工廠模式就相當(dāng)于創(chuàng)建實例對象的new，雖然這樣做，可能多做一些工作，但會給系統(tǒng)帶來更大的可擴展性和盡量少的修改量。在實際應(yīng)用中，工廠方法用得比較多一些，而且是和動態(tài)類裝入器組合在一起應(yīng)用。u簡單工廠(SimpleFactory)u工廠方法(FactoryMethod)u抽象工廠(AbstractFactory)工廠模式-簡單工廠p簡單工廠UMLCreator+factory(): ProductConcreteProductProduct工廠模式-

13、簡單工廠p簡單工廠模式特點優(yōu)點： 模式的核心是工廠類，該類中含有必要的判斷邏輯，可以決定在什么時候創(chuàng)建哪一個產(chǎn)品類的實例，客戶端可以免除直接創(chuàng)建產(chǎn)品對象的責(zé)任，而僅僅負(fù)責(zé)“消費”產(chǎn)品。 簡單工廠模式實現(xiàn)了對責(zé)任的分割。缺點： 當(dāng)產(chǎn)品類有復(fù)雜的多層次等級結(jié)構(gòu)時，工廠類只有它自己。以不變應(yīng)萬變。 模式中工廠類集中了所有的產(chǎn)品創(chuàng)建邏輯，形成一個無所不知的全能類。 將多個創(chuàng)建邏輯放在一個類中，當(dāng)產(chǎn)品類有不同接口種類時，工廠類需要判斷在什么時候創(chuàng)建某種產(chǎn)品，使得系統(tǒng)在將來進(jìn)行功能擴展時較為困難。 該模式采用靜態(tài)方法作為工廠方法，而靜態(tài)方法無法由子類繼承，因此工廠角色無法形成基于繼承的等級結(jié)構(gòu)。工廠模式-

14、工廠方法p工廠方法UMLCreator+factory(): ProductConcreteProduct1ProductConcreteProduct2ConcreteCreator1+factory(): ProductConcreteCreator2+factory(): Product工廠模式-工廠方法p工廠方法模式特點 優(yōu)點： 多態(tài)性：客戶代碼可以做到與特定應(yīng)用無關(guān)，適用于任何實體類。 子類提供掛鉤?；悶楣S方法提供缺省實現(xiàn)，子類可以重寫新的實現(xiàn)，也可以繼承父類的實現(xiàn)。- 加一層間接性，增加了靈活性 連接并行的類層次結(jié)構(gòu)。 良好的封裝性，代碼結(jié)構(gòu)清晰。 擴展性好，在增加產(chǎn)品類的情況

15、下，只需要適當(dāng)修改具體的工廠類或擴展一個工廠類，就可“擁抱變化”。 屏蔽產(chǎn)品類。產(chǎn)品類的實現(xiàn)如何變化，調(diào)用者都不需要關(guān)心，只需關(guān)心產(chǎn)品的接口，只要接口保持不變，系統(tǒng)中的上層模塊就不會發(fā)生變化。 典型的解耦框架。高層模塊只需要知道產(chǎn)品的抽象類，其他的實現(xiàn)類都不需要關(guān)心，符合迪米特法則，符合依賴倒置原則，符合里氏替換原則。 缺點： 需要Creator和相應(yīng)的子類作為factory method的載體，如果應(yīng)用模型確實需要creator和子類存在，則很好；否則的話，需要增加一個類層次。工廠模式p抽象工廠UMLCreator+factoryA(): ProductA+factoryB(): Produ

16、ctBProductA1ProductAProductA2ConcreteCreator1+factoryA(): ProductA+factoryB(): ProductBConcreteCreator2+factoryA(): ProductA+factoryB(): ProductBProductBProductB1ProductB2工廠模式- 抽象工廠p抽象工廠特點優(yōu)點： 分離了具體的類，一個工廠封裝創(chuàng)建產(chǎn)品對象的責(zé)任和過程，它將客戶與類的實現(xiàn)分離 易于交換產(chǎn)品系列，只需改變具體的工廠就可以使用不同的產(chǎn)品配置。 有利于產(chǎn)品的一致性，當(dāng)一個系列中的產(chǎn)品對象被設(shè)計成一起工作時，一個應(yīng)用一次

17、只能使用同一個系列中的對象。缺點： 難以支持新的產(chǎn)品等級結(jié)構(gòu)，支持新的產(chǎn)品等級結(jié)構(gòu)就要擴展抽象工廠接口。Java設(shè)計模式-創(chuàng)建模式p創(chuàng)建模式-原型模式（Prototype）Prototype模式允許一個對象再創(chuàng)建另外一個可定制的對象，根本無需知道任何如何創(chuàng)建的細(xì)節(jié)，工作原理是：通過將一個原型對象傳給那個要發(fā)動創(chuàng)建的對象，這個要發(fā)動創(chuàng)建的對象通過請求原型對象拷貝它們自己來實施創(chuàng)建。因為Java中的提供clone()方法來實現(xiàn)對象的克隆，所以Prototype模式實現(xiàn)一下子變得很簡單。Java設(shè)計模式-創(chuàng)建模式p創(chuàng)建模式-生成器模式（Builder）將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)

18、建過程可以創(chuàng)建不同的表示。Builder模式是一步一步創(chuàng)建一個復(fù)雜的對象，它允許用戶可以只通過指定復(fù)雜對象的類型和內(nèi)容就可以構(gòu)建它們。用戶不知道內(nèi)部的具體構(gòu)建細(xì)節(jié)。p為何使用是為了將構(gòu)建復(fù)雜對象的過程過程和它的部件部件解耦。因為一個復(fù)雜的對象，不但有很多大量組成部分，如汽車，有很多部件:車輪、方向盤、發(fā)動機、還有各種小零件等等，部件很多，但遠(yuǎn)不止這些，如何將這些部件裝配成一輛汽車，這個裝配過程也很復(fù)雜，Builder模式就是為了將部件和組裝過程分開。生成器模式p生成器模式UMLDirector-builder: Builder+Director()+construct(): voidBuild

19、er+buildPart1(): void+buildPart2(): void+getResult(): ProductConcreteBuilder+buildPart1(): void+buildPart2(): void+getResult(): ProductProduct1public void construct() builder = new ConcreteBuilder(); builder.buildPart1(); builder.buildPart2(); builder.getResult(); /other codeProduct生成器模式特點p生成器模式優(yōu)點：他

20、使你可以改變一個產(chǎn)品的內(nèi)部表示它將構(gòu)造代碼和表示代碼分開它使你可對構(gòu)造過程進(jìn)行更精細(xì)的控制Java設(shè)計模式-創(chuàng)建模式p創(chuàng)建模式-單態(tài)模式（Singleton）Singleton模式主要作用是保證在Java應(yīng)用程序中，一個類Class只有一個實例存在。在很多操作中，比如建立目錄、數(shù)據(jù)庫連接都需要這樣的單線程操作。還有，Singleton能夠被狀態(tài)化;這樣，多個單態(tài)類在一起就可以作為一個狀態(tài)倉庫一樣向外提供服務(wù)，比如，你要論壇中的帖子計數(shù)器，每次瀏覽一次需要計數(shù)，單態(tài)類能否保持住這個計數(shù)，并且能synchronize的安全自動加1，如果你要把這個數(shù)字永久保存到數(shù)據(jù)庫，你可以在不修改單態(tài)接口的情況下

21、方便的做到。另外方面，Singleton也能夠被無狀態(tài)化，提供工具性質(zhì)的功能。Java設(shè)計模式-結(jié)構(gòu)模式p結(jié)構(gòu)模式外觀模式（Facade）代理模式（Proxy）適配器模式（Adapter）組合模式（Composite）裝飾模式（Decorator）橋接模式（Bridge）享元模式（Flyweight）Java設(shè)計模式-外觀模式p結(jié)構(gòu)模式-外觀模式（Facade）為子系統(tǒng)中的一組接口提供一個一致的界面，例如：數(shù)據(jù)庫JDBC的應(yīng)用。Java設(shè)計模式-代理模式p結(jié)構(gòu)模式-代理模式（Proxy）對于開銷很大的對象，只有在使用它時才創(chuàng)建，使用代理原則可以為我們節(jié)省很多寶貴的Java內(nèi)存。Java設(shè)計模式

22、-適配器模式p結(jié)構(gòu)模式-適配器模式（Adapter）如何將兩個不兼容的類糾合在一起使用，通常的解決方案是：修改各自類的接口，但是如果我們沒有源代碼，或者我們不愿意為了一個應(yīng)用而修改各自的接口，怎么辦?Java設(shè)計模式-組合模式p結(jié)構(gòu)模式-組合模式（Composite）將對象組合成樹形結(jié)構(gòu)以表示“整體部分”的層次結(jié)構(gòu)。Composite模式使單個對象和組合對象的使用具有一致性。Composite將遍歷(Iterator)整個樹形結(jié)構(gòu)，尋找同樣包含這個方法的對象并實現(xiàn)調(diào)用執(zhí)行。Java設(shè)計模式-裝飾模式p結(jié)構(gòu)模式-裝飾模式（Decorator）裝飾模式是在不必改變原類文件和使用繼承的情況下，動態(tài)的

23、擴展一個對象的功能。它是通過創(chuàng)建一個包裝對象，也就是裝飾來包裹真實的對象。結(jié)構(gòu)模式-裝飾模式p裝飾模式UMLComponent+operation(): voidComcreteComponent+operation(): voidDecorator+component: Component+Decorator()+Decorator(: Component)+operation(): voidpublic void operation() component.operation();ComcreteDecoratorA-AddedState+operation(): voidComcrete

24、DecoratorB+operation(): void+addBehavior()public void operation() super.operation(); /在此或者其他地方添加行為， 以擴展Component addBehavior();結(jié)構(gòu)模式-裝飾模式p裝飾模式特點比繼承更靈活從為對象添加功能的角度來看，裝飾模式比繼承來得更靈活。繼承是靜態(tài)的，而且一旦繼承是所有子類都有一樣的功能。而裝飾模式采用把功能分離到每個裝飾器當(dāng)中，然后通過對象組合的方式，在運行時動態(tài)的組合功能，每個被裝飾的對象，最終有哪些功能，是由運行期動態(tài)組合的功能來決定的。更容易復(fù)用功能裝飾模式把一系列復(fù)雜的功

25、能，分散到每個裝飾器當(dāng)中，一般一個裝飾器只實現(xiàn)一個功能，這樣實現(xiàn)裝飾器變得簡單，更重要的是這樣有利于裝飾器功能的復(fù)用，可以給一個對象增加多個同樣的裝飾器，也可以把一個裝飾器用來裝飾不同的對象，從而復(fù)用裝飾器的功能。簡化高層定義裝飾模式可以通過組合裝飾器的方式，給對象增添任意多的功能，因此在進(jìn)行高層定義的時候，不用把所有的功能都定義出來，而是定義最基本的就可以了，可以在使用需要的時候，組合相應(yīng)的裝飾器來完成需要的功能。會產(chǎn)生很多細(xì)粒度對象前面說了，裝飾模式是把一系列復(fù)雜的功能，分散到每個裝飾器當(dāng)中，一般一個裝飾器只實現(xiàn)一個功能，這樣會產(chǎn)生很多細(xì)粒度的對象，而且功能越復(fù)雜，需要的細(xì)粒度對象越多。J

26、ava設(shè)計模式-橋接模式p結(jié)構(gòu)模式-橋接模式（Bridge）Bridge模式是一種抽象與其實現(xiàn)相分離的模式。它主要應(yīng)用于：當(dāng)事物是一組變化量，和對這些事物的操作方法(實現(xiàn))也是一組變化量的情況，也就是說它們都是多變的。Java設(shè)計模式-享元模式p結(jié)構(gòu)模式-享元模式（Flyweight）運用共享技術(shù)有效地支持大量細(xì)粒度對象。也就是說在一個系統(tǒng)中如果有多個相同的對象，那么只共享一份就可以了，不必每個都去實例化一個對象。Flyweight模式是一個提高程序效率和性能的模式，會大大加快程序的運行速度。例如：Xml文件中的數(shù)據(jù)處理。Java設(shè)計模式-行為模式p行為模式 模板模式（Template） 備忘

27、機制模式（Memento） 觀察者模式（Observer） 職責(zé)鏈模式（ChainofResponsibility） 命令模式（Command） 狀態(tài)模式（State） 策略模式（Strategy） 中介者模式（Mediator） 解釋器模式（Interpreter） 參觀者模式（Visitor）Java設(shè)計模式-行為模式p行為模式-觀察者模式（Observer）定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都將得到通知并自動更新。具體的說，如果我們希望網(wǎng)上商店的商品在名稱、價格等方面有變化時，系統(tǒng)就能自動通知會員，這時就需要使用Observer模式。行為模式-觀察者模式p觀察者模式UMLSubject-observersList: List+attach(Observer): void+detach(Observer): void+no