設計模式優(yōu)缺點及應用場景整理

1、精選優(yōu)質文檔-傾情為你奉上看完發(fā)現(xiàn)有不太對的地方告訴我下各設計模式優(yōu)缺點總結1橋接模式優(yōu)點：1 將實現(xiàn)予以解耦，讓它和界面之間不再永久綁定 2 抽象和實現(xiàn)可以獨立擴展，不會影響到對方 3 對于“具體的抽象類”所做的改變，不會影響到客戶。缺點：1. 增加了復雜度 用途：1. 適合使用在需要跨越多個平臺的圖形和窗口上 2. 當需要用不同的方式改變接口和實現(xiàn)時，你會發(fā)現(xiàn)橋接模式很好用。具體實例：跨平臺的軟件，不同電視機和不同的遙控器。2生成器模式（建造者模式）優(yōu)點：1. 將一個復雜對象的創(chuàng)建過程封裝起來2. 允許對象通過多個步驟來創(chuàng)建，并且可以改變創(chuàng)建過程3. 向客戶隱藏內部的表現(xiàn)4. 產品的實現(xiàn)可

2、以被替換，因為客戶只看到一個抽象的接口缺點：1. 與工廠模式相比，采用生成器模式創(chuàng)建對象更復雜，其客戶，需要更多的知識領域。用處：用來創(chuàng)建組合結構。典型例子：想不起典型例子還是扯那個畫小人，構建小人分畫頭，畫身體，畫雙手，黃雙腳等不同構建部分，全部放在一起構建。3職責鏈模式優(yōu)點：1. 將請求的發(fā)送者和接收者解耦2. 可以簡化你的對象，因為它不需要知道鏈的結構3. 通過改變鏈內的成員或調動他們的次序，允許你動態(tài)地新增或刪除責任缺點：1. 并不保證請求一定會被執(zhí)行，如果沒有任何對象處理它的話，它可能會落到鏈尾端之外2. 可能不容觀察運行時的特征，有礙于除錯。用途：經常被使用在窗口系統(tǒng)中，處理鼠標和

3、鍵盤之類的事件。當算法牽涉到一種鏈型運算，而且不希望處理過程中有過多的循環(huán)和條件選擇語句，并且希望比較容易的擴充文法，可以采用職責鏈模式。1）有多個對象處理請求，到底怎么處理在運行時確定。2）希望在不明確指定接收者的情況下，向多個對象中的一個提交請求。3）可處理一個請求的對象集合應該被動態(tài)指定。典型例子：一個請求發(fā)送給前臺，前臺表示我無權管理，將請求傳遞給財務部門，財務部門再4蠅量模式（享元）優(yōu)點：1. 減少運行時對象實例的個數(shù)，節(jié)省內存2. 將許多“虛擬”對象的狀態(tài)集中管理缺點：一旦你實現(xiàn)了它，單個的邏輯實現(xiàn)將無法擁有獨立而不同的行為用途：當一個類有許多的實例，而這些實例能被同一方法控制的時

4、候，我們就可以使用蠅量模式。（這話什么意思啊，HF書上原話，是這話有問題還是我理解能力有問題?!）具體場景：五子棋中的黑白子，改變坐標狀態(tài)(x,y)，但用同一個實體。5解釋器模式（這個模式我真沒仔細看）優(yōu)點：1 將每一個語法規(guī)則表示成一個類，方便事先語言。2 因為語法由許多類表示，所以你可以輕易地改變或擴展此語言3 通過在類結構中加入新的方法，可以在解釋的同時增加新的行為，例如打印格式的梅花或者進行復制的程序驗證。缺點：當語法規(guī)則數(shù)目太大時，這個模式可能會變得非常繁瑣。用途：1 當你需要實現(xiàn)一個簡答的語言時，使用解釋器2 當你有一個簡單的語法，切簡單比效率更重要時，使用解釋器3 可以處理腳本語

5、言和編程語言典型例子：正則表達式6中介者模式優(yōu)點：1. 通過將對象彼此解耦，可以增加對象的復用性。2. 通過將控制邏輯集中，可以簡化系統(tǒng)維護3. 可以讓對象之間傳遞的消息變得簡單而且大幅減少缺點：1. 如果設計不當，中介者對象本身會變得過于復雜用途：常常被用來協(xié)調相關的GUI組件(HF設計模式上的原話，這書附錄A部分真的有點敷衍)經典例子：我租房，但沒有戶主信息，我和戶主不能直接交替。沒關系，中介者類有我和戶主的信息，private我，private戶主。而我和戶主都認識中介者。我將信息傳遞給中介者，在我中調用中介者.獲取信息（）方法，中介者獲取信息后，再由中介者傳遞給戶主。7備忘錄模式優(yōu)點：

6、1. 將被存儲的狀態(tài)放在外面，不要和關鍵對象混在一起，可以幫助維護內聚2. 保持關鍵對象的數(shù)據(jù)封裝3. 提供了容易實現(xiàn)的恢復能力缺點：1. 儲存和恢復狀態(tài)的過程可能相當耗時用途備忘錄模式用于存儲狀態(tài)，在java中可以使用序列化。經典例子：游戲中途保存游戲，這時候可以調用保存當前狀態(tài)方法，再讀取的時候調用讀取。Java序列化機制在這方面非常的方便。8原型模式優(yōu)點：1. 向客戶隱藏制造新實例的復雜性2. 提供讓客戶能夠產生未知類型對象的選項3. 在某些環(huán)境下，復制對象比新建對象更有效缺點：復制對象有時相當復雜用途：在一個復制的類層次中，當系統(tǒng)必須從其中的許多類型創(chuàng)建新對象時，可以考慮原型模式。經典

7、例子：隨便拿一個類，給這個類寫一個克隆方法，復制當前對象?；蛘咧苯佑梅葱蛄谢?。9訪問者模式優(yōu)點：1. 允許你對組合結構加入新的操作，無需改變結構本身2. 想要加入新的操作相對容易3. 訪問者所進行的操作，其代碼是集中在一起的缺點：1. 會打破組合類的封裝2. 因為游走的功能牽涉其中，隨意對組合結構的改變就更加困難。用途：有比較穩(wěn)定的數(shù)據(jù)結構，又有易于變化的算法的話，使用訪問者模式就是比較合適的，因為訪問者模式使得算法操作的增加變得容易。經典場景：特么訪問者模式和翻譯器模式，一個看不懂，一個怎么也不想看，到時候要是讓我說這兩個模式，我就自認倒霉。10簡單工廠模式優(yōu)點：工廠類是整個模式的關鍵.包含

8、了必要的邏輯判斷,根據(jù)外界給定的信息,決定究竟應該創(chuàng)建哪個具體類的對象.通過使用工廠類,外界可以從直接創(chuàng)建具體產品對象的尷尬局面擺脫出來,僅僅需要負責“消費”對象就可以了。而不必管這些對象究竟如何創(chuàng)建及如何組織的明確了各自的職責和權利，有利于整個軟件體系結構的優(yōu)化。缺點：由于工廠類集中了所有實例的創(chuàng)建邏輯，違反了高內聚責任分配原則，將全部創(chuàng)建邏輯集中到了一個工廠類中；它所能創(chuàng)建的類只能是事先考慮到的，如果需要添加新的類，則就需要改變工廠類了。當系統(tǒng)中的具體產品類不斷增多時候，可能會出現(xiàn)要求工廠類根據(jù)不同條件創(chuàng)建不同實例的需求這種對條件的判斷和對具體產品類型的判斷交錯在一起，很難避免模塊功能的蔓

9、延，對系統(tǒng)的維護和擴展非常不利；用途：工廠類負責創(chuàng)建的對象比較少；客戶只知道傳入工廠類的參數(shù)，對于如何創(chuàng)建對象（邏輯）不關心；由于簡單工廠很容易違反高內聚責任分配原則，因此一般只在很簡單的情況下應用。經典例子：沒啥好說的，這不是一個真正的設計模式11策略模式優(yōu)點：1. 提供了一種替代繼承的方法，而且保持了繼承的優(yōu)點，比繼承更獨立(算法獨立，可以任意擴展)2. 避免程序使用多重條件轉移語句，使系統(tǒng)更靈活，并易于擴展3. 遵守大部分常用設計原則，高內聚，低耦合缺點：1. 每個具體策略類都會產生一個新類，所以會增加系統(tǒng)需要維護的類的數(shù)量?？梢允褂霉S方法來解決。用途：各個不同地區(qū)不同的納稅方法，HF

10、中不同鴨子的方法。有多種鴨子，每個鴨子都有自己的行為，fly，quaak之類的。行為有行為類，繼承同一接口實現(xiàn)不同操作，以此實現(xiàn)算法互換。12裝飾模式優(yōu)點：1. 裝飾模式與繼承關系的目的都是要擴展對象的功能，但是裝飾模式可以提供比繼承更多的靈活性。2. 通過使用不同的具體裝飾類以及這些裝飾類的排列組合，設計師可以創(chuàng)造出很多不同行為的組合。3. 有著比繼承更加靈活的特性缺點：由于使用裝飾模式，可以比使用繼承關系需要較少數(shù)目的類。使用較少的類，當然使設計比較易于進行。但是，在另一方面，使用裝飾模式會產生比使用繼承關系更多的對象。更多的對象會使得查錯變得困難，特別是這些對象看上去都很相像。用途：當需

11、要給一個類添加新的行為的時候，但基于開閉原則，就使用裝飾模式。經典例子：我穿衣服使用draw（）方法，在我穿好衣服后，我還打算再寄領帶，而寄領帶就是裝飾類，我們可以把裝飾類和對象（穿衣服類）繼承于同一個接口，在裝飾類的draw（）方法中調用super.draw（），然后再在這個方法里加上自己的特征。13代理模式優(yōu)點：向客戶端隱藏了訪問某個對象的細節(jié)及復雜性；可以動態(tài)地調用一個對象中的方法，且無需實現(xiàn)固定的接口。缺點：（個人見解切勿當真）總覺得代理者不夠可靠，不能得到有效的保證，要是對象代理者在維護的時候，或者其他的做出了變動，對被代理的人來說可能帶來損失。使用場景：1. 遠程代理，可以隱藏一個

12、對象存在于不同地址空間的事實2. 虛擬代理，比如html頁面刷新的圖片，圖片一張嘴下載后才能看就是通過虛擬代理來替代了真實的圖片，此時代理存儲了真實圖片的路徑和尺寸3. 安全代理，用來控制真實對象的訪問權限。一般用于對象應該有不同的訪問權限的時候4. 智能指引，當調用真實的對象時，代理處理另外一些事。經典例子：我玩wow，但又沒有時間精力投入到里面，于是我請了個人來代練，代練的人和我都繼承于玩家類。而代練者是認識我的，當代練的人開始刷副本的時候，調用代練者.刷副本（）方法,此時他在這個方法中實際調用的是我.刷副本（）。14工廠方法模式優(yōu)點：1. 良好的封裝性，代碼結構清晰。一個對象創(chuàng)建是有條件

13、約束的，如一個調用者需要一個具體的產品對象，只要知道這個產品的類名（或約束字符串）就可以了，不用知道創(chuàng)建對象的艱辛過程，減少模塊間的耦合。2. 工廠方法模式的擴展性非常優(yōu)秀。在增加產品類的情況下，只要適當?shù)匦薷木唧w的工廠類或擴展一個工廠類，就可以完成“擁抱變化”。例如在我們的例子中，需要增加一個棕色人種，則只需要增加一個BrownHuman類，工廠類不用任何修改就可完成系統(tǒng)擴展。3. 屏蔽產品類。這一特點非常重要，產品類的實現(xiàn)如何變化，調用者都不需要關心，它只需要關心產品的接口，只要接口保持不表，系統(tǒng)中的上層模塊就不要發(fā)生變化，因為產品類的實例化工作是由工廠類負責，一個產品對象具體由哪一個產品

14、生成是由工廠類決定的。在數(shù)據(jù)庫開發(fā)中，大家應該能夠深刻體會到工廠方法模式的好處：如果使用JDBC連接數(shù)據(jù)庫，數(shù)據(jù)庫從MySql切換到Oracle，需要改動地方就是切換一下驅動名稱（前提條件是SQL語句是標準語句），其他的都不需要修改，這是工廠方法模式靈活性的一個直接案例。4. 工廠方法模式是典型的解耦框架。高層模塊值需要知道產品的抽象類，其他的實現(xiàn)類都不用關心，符合迪米特原則，我不需要的就不要去交流；也符合依賴倒轉原則，只依賴產品類的抽象；當然也符合里氏替換原則，使用產品子類替換產品父類，沒問題！缺點：待補充用途：第一種情況是對于某個產品，調用者清楚地知道應該使用哪個具體工廠服務，實例化該具體

15、工廠，生產出具體的產品來。Java Collection中的iterator() 方法即屬于這種情況。第二種情況，只是需要一種產品，而不想知道也不需要知道究竟是哪個工廠為生產的，即最終選用哪個具體工廠的決定權在生產者一方，它們根據(jù)當前系統(tǒng)的情況來實例化一個具體的工廠返回給使用者，而這個決策過程這對于使用者來說是透明的。典型例子：車子繼承vehicle（車）類，有小汽車卡，公交車bus等，車子工廠實現(xiàn)工廠接口，工廠接口有抽象方法vehicle produce vehicle（String type）方法，車子工廠中實現(xiàn)工廠方法vehicle produce vehicle（String Type

16、），方法中根據(jù)需要new新的車子。15模板方法模式優(yōu)點：模板方法模式通過把不變的行為搬移到超類，去除子類中的重復代碼來體現(xiàn)它的優(yōu)勢。模板方法模式提供了一個很好的代碼復用平臺。缺點：沒啥明顯缺點吧？簡單實用的設計模式。用途：當不變的和可變的行為在方法的子類實現(xiàn)中混合在一起的時候，不變的行為會在子類中重復出現(xiàn)，我們可以通過模板方法牧師把這些行為搬移到單一的地方（方法）中，這樣就幫助子類擺脫重復的不變行為的糾纏。典型例子：泡茶和泡咖啡兩個動作很像，都有煮開水（）方法，放入茶或咖啡（）方法，把泡好的導入被子，加調料，這四個動作在一起算是完成泡咖啡行為。在這里，我們可以把泡茶和泡咖啡都繼承于抽象類飲料中

17、，而飲料類有個模板方法，templateMethod（）這個方法封裝其他幾個行為方法。而客戶端想執(zhí)行那幾個方法的時候，只需要調用emplateMethod（）模板方法。我們會把templateMethod（）方法用final修飾，以免這個算法骨架被重寫而改變。16外觀模式優(yōu)點：1. 對客戶屏蔽了其子系統(tǒng)組件，因而減少了客戶處理對象的數(shù)目，并使得子系統(tǒng)實用起來更方便2. 它實現(xiàn)了子系統(tǒng)與客戶之間的松耦合關系，而子系統(tǒng)內部的功能組件往往是緊耦合的。松耦合關系使得子系統(tǒng)的組件變化不會影響到它的客戶。 Facade模式有助于建立層次結構系統(tǒng)，也有助于對對象之間的依賴關系分層。 Facade模式還可以消

18、除復雜的循環(huán)依賴關系，這一點在客戶程序與子系統(tǒng)是分別實現(xiàn)的時候尤為重要。3. 如果應用需要，它并不限制它們實用子系統(tǒng)類。因此你可以在系統(tǒng)易用性和通用性之間進行選擇。缺點：限制了客戶的自由，減少了可變性。用途：a) 為一個復雜子系統(tǒng)提供一個簡單接口.b) 提高子系統(tǒng)的獨立性.c) 在層次化結構中，可以使用Facade模式定義系統(tǒng)中每一層的入口。典型例子魔獸插件一鍵換裝，會同時調用更換掉身上的裝備接口和更換角色天賦的接口。17觀察者模式優(yōu)點：1.  觀察者和被觀察者之間是松耦合的，分別可以各自獨立改變。2. Subject在發(fā)送廣播通知的時候，無須指定具體的Observer，Observ

19、er可以自己決定是否要訂閱Subject的通知。3. 遵守大部分GRASP原則和常用設計原則，高內聚、低耦合。缺點：1. 松耦合導致代碼關系不明顯，有時可能難以理解。2. 如果一個對象被大量觀察者訂閱的話，在廣播通知的時候可能會有效率問題。（畢竟只是簡單的遍歷）使用場景1、 對一個對象狀態(tài)的更新，需要其他對象同步更新，而且其他對象的數(shù)量動態(tài)可變。2、 對象僅需要將自己的更新通知給其他對象而不需要知道其他對象的細節(jié)。經典例子：看電視，天氣預報看新聞聯(lián)播，觀眾們是觀察者，新聞聯(lián)播是對象，每個觀察者都繼承于一個統(tǒng)一的接口。而被觀察的對象是新聞聯(lián)播，新聞聯(lián)播可以添加新的觀察者，或者當移除觀察者（關電視

20、不看），新聞聯(lián)播對象有個通知用戶信息變更方法，當達到某種條件是，新聞聯(lián)播對象會將信息都通知給觀察者。18抽象工廠模式優(yōu)點：1. 抽象工廠模式隔離了具體類的生產，使得客戶并不需要知道什么被創(chuàng)建2. 當一個產品族中的多個對象被設計成一起工作時，它能保證客戶端始終只使用同一個產品族中的對象3. 增加新的具體工廠和產品族很方便，無須修改已有系統(tǒng)，符合“開閉原則”缺點：增加新的產品等級結構很復雜，需要修改抽象工廠和所有的具體工廠類，對“開閉原則”的支持呈現(xiàn)傾斜性。用途：1、一個系統(tǒng)不應當依賴于產品類實例如何被創(chuàng)建、組合和表達的細節(jié)，這對于所有類型的工廠模式都是重要的。2、系統(tǒng)中有多于一個的產品族，而每次

21、只使用其中某一產品族。3、屬于同一個產品族的產品將在一起使用，這一約束必須在系統(tǒng)的設計中體現(xiàn)出來。4、系統(tǒng)提供一個產品類的庫，所有的產品以同樣的接口出現(xiàn)，從而使客戶端不依賴于具體實現(xiàn)。經典例子：抽象工廠在我的理解就是抽象工廠有兩個或兩個個以上的工廠方法模式結合，有一個工廠接口類，這個接口有中的產品家族有發(fā)動機和輪胎兩個產品。有兩個具體工廠，米其林工廠和倍耐力工廠實現(xiàn)了抽象工廠。米其林工廠生產的輪胎都繼承于米其林輪胎，同理米其林發(fā)動機和倍耐力產品。19狀態(tài)模式優(yōu)點：1. 把狀態(tài)的判斷邏輯轉移到表示不同狀態(tài)的一系列類當中，可以把復雜的判斷邏輯簡化。2. 將與特定狀態(tài)相關的行為局部化，并且將不同狀態(tài)

22、的行為分割開來。3. 通過把各種狀態(tài)轉移邏輯分不到狀態(tài)與其子類之間，來減少相互間的依賴。缺點：策略模式，每個具體狀態(tài)類都會產生一個新類，所以會增加系統(tǒng)需要維護的類的數(shù)量?？梢允褂霉S方法來解決。（我只是把策略二字換成了狀態(tài)）用途：1.一個對象的行為取決于它的狀態(tài)，并且它必須在運行時刻根據(jù)狀態(tài)改變它的行為。2.一個操作中含有龐大的多分支結構，并且這些分支決定于對象的狀態(tài)。經典例子：我上班，上午點，下午，晚上各個時間段不同狀態(tài)不同算法。這三個狀態(tài)都繼承一個統(tǒng)一的狀態(tài)類。都有重寫work（）方法，在我調用work的時候，會根據(jù)不同的狀態(tài)調用不同的work。20適配器模式優(yōu)點：1. 將目標類和適配者類

23、解耦2. 增加了類的透明性和復用性，將具體的實現(xiàn)封裝在適配者類中，對于客戶端類來說是透明的，而且提高了適配者的復用性3. 靈活性和擴展性都非常好，符合開閉原則缺點：一次最多只能適配一個適配者類，而且目標抽象類只能為接口，不能為類，其使用有一定的局限性，不能將一個適配者類和他的子類同時適配到目標接口。用途：想使用一個已經存在的類，但如果它的接口和你的要求不相同時?？梢允褂眠m配器模式。兩個類所做的事情相同或相似，但接口不同時可以使用。經典例子：不同牌子電視機和不同牌子遙控器，里皮翻譯用漢語布置恒大隊員戰(zhàn)術，不同牌子手機的軟件。球員都繼承于中國人，都會說漢語，而里皮并不會說漢語。在不知戰(zhàn)術的時候，我

24、們需要給里皮一個翻譯，這個翻譯就是里皮的適配器。翻譯可以和球員一樣，也繼承于中國人，也有說漢語這個方法。而翻譯認識里皮，翻譯在說漢語（）這個方法的時候，實際上是在說里面用意大利語的內容。Fanyi.shuohanyu()Lipi.yidaliyu();21組合模式優(yōu)點：1. 使客戶端調用簡單，客戶端可以一致的使用組合結構或其中單個對象，用戶就不必關心自己處理的是單個對象還是整個組合結構，這就簡化了客戶端代碼。2. 更容易在組合體內加入對象部件. 客戶端不必因為加入了新的對象部件而更改代碼。這一點符合開閉原則的要求，對系統(tǒng)的二次開發(fā)和功能擴展很有利！缺點：組合模式不容易限制組合中的構件用途：當你

25、發(fā)現(xiàn)需求中是體現(xiàn)部分與整體層次的結構時，以及你希望可以忽略組合對象與單個對象的不同，統(tǒng)一地使用組合結構中的所有對象時，就應該考慮使用組合模式了。典型例子：樹形結構，android界面控件22迭代器模式優(yōu)點：1. 簡化了遍歷方式，對于對象集合的遍歷，還是比較麻煩的，對于數(shù)組或者有序列表，我們尚可以通過游標來取得，但用戶需要在對集合了解很清楚的前提下，自行遍歷對象，但是對于hash表來說，用戶遍歷起來就比較麻煩了。而引入了迭代器方法后，用戶用起來就簡單的多了。2. 可以提供多種遍歷方式，比如說對有序列表，我們可以根據(jù)需要提供正序遍歷，倒序遍歷兩種迭代器，用戶用起來只需要得到我們實現(xiàn)好的迭代器，就可

26、以方便的對集合進行遍歷了。3. 封裝性良好，用戶只需要得到迭代器就可以遍歷，而對于遍歷算法則不用去關心。缺點：對于比較簡單的遍歷（像數(shù)組或者有序列表），使用迭代器方式遍歷較為繁瑣，大家可能都有感覺，像ArrayList，我們寧可愿意使用for循環(huán)和get方法來遍歷集合，操作簡易度完爆迭代。用途： 迭代器模式是與集合共生共死的，一般來說，我們只要實現(xiàn)一個集合，就需要同時提供這個集合的迭代器，就像java中的Collection，List、Set、Map等，這些集合都有自己的迭代器。假如我們要實現(xiàn)一個這樣的新的容器，當然也需要引入迭代器模式，給我們的容器實現(xiàn)一個迭代器。 但是，由于容器與迭代器的關系太密切了，所以大多數(shù)語言在實現(xiàn)容器的時候都給提供了迭代器，并且這些語言提供的容器和迭代器在絕大多數(shù)情況下就可以滿足我們的需要，所以現(xiàn)在需要我們自己去實踐迭代器模式的場景還是比較少見的，我們只需要使用語言中已有的容器和迭代器就可以了。 典型例子：Iterator用多了，想不出啥經典例子。23單例模式優(yōu)點：1.