C# 23種設(shè)計模式匯總 創(chuàng)建型模式 工廠方法（Factory Method） 在工廠方法模式中，工廠方法用來創(chuàng)建客戶所需要的產(chǎn)品，同時還向客戶隱藏了哪種具體產(chǎn)品類將被實例化這一細節(jié)。工廠方法模式的核心是一個抽象工廠類，各種具體工廠類通過抽象工廠類將工廠方法繼承下來。如此使得客戶可以只關(guān)心抽象產(chǎn)品和抽象工廠，完全不用理會返回的是哪一種具體產(chǎn)品，也不用關(guān)系它是如何被具體工廠創(chuàng)建的。抽象工廠模式（Abstract Factory） 抽象工廠模式的主要優(yōu)點是隔離了具體類的生成，使得客戶不需要知道什么被創(chuàng)建了。猶豫這種隔離，更換一個具體工廠就變得相對容易。所有的具體工廠都實現(xiàn)了抽象工廠中定義的那些公共接口，因此只需改變具體工廠的實例，就可以在某種程度上改變這個軟件的系統(tǒng)的行為。另外，應(yīng)用抽象工廠模式符合GRASP純虛構(gòu)的模式，可以實現(xiàn)高內(nèi)聚低耦合的設(shè)計目的，因此抽象工廠模式得到了廣泛應(yīng)用。建造者模式（Builder Pattern） 建造者模式將一個復(fù)雜對象的生成責(zé)任作了很好的分配。它把構(gòu)造過程放在指揮者的方法中，把裝配過程放到具體建造者類中。建造者模式的產(chǎn)品之間都有共通點，但有時候，產(chǎn)品之間的差異性很大，這就需要借助工廠方法模式或抽象工廠模式。另外，如果產(chǎn)品的內(nèi)部變化復(fù)雜，Builder的每一個子類都需要對應(yīng)到不同的產(chǎn)品去做構(gòu)建的動作、方法，這就需要定義很多個具體建造類來實現(xiàn)這種變化。單件模式（Single Pattern） Singleton單例模式為一個面向?qū)ο蟮膽?yīng)用程序提供了對象唯一的訪問點，不管它實現(xiàn)何種功能，此種模式都為設(shè)計及開發(fā)團隊提供了共享的概念。然而，Singleton對象類派生子類就有很大的困難，只有在父類沒有被實例化時才可以實現(xiàn)。值得注意的是，有些對象不可以做成Singleton，比如.net的數(shù)據(jù)庫鏈接對象(Connection)，整個應(yīng)用程序同享一個Connection對象會出現(xiàn)連接池溢出錯誤。另外，.net提供了自動廢物回收的技術(shù)，因此，如果實例化的對象長時間不被利用，系統(tǒng)會認為它是廢物，自動消滅它并回收它的資源，下次利用時又會重新實例化，這種情況下應(yīng)注意其狀態(tài)的丟失。原型模式（Protype Pattern） 原型模式得到了廣泛的應(yīng)用，特別是在創(chuàng)建對象成本較大的情況下(初始化需占用較長時間，占用太多CPU資源或網(wǎng)絡(luò)資源。比如通過Webservice或DCOM創(chuàng)建對象，或者創(chuàng)建對象要裝載大文件)，系統(tǒng)如果需要重復(fù)利用，新的對象可以通過原型模式對已有對象的屬性進行復(fù)制并稍作修改來取得。另外，如果系統(tǒng)要保存對象的狀態(tài)而對象的狀態(tài)變化很小，或者對象本身占內(nèi)存不大的時候，也可以用原型模式配合備忘錄模式來應(yīng)用。相反地，如果對象的狀態(tài)變化很大，或者對象占用內(nèi)存很大，那么采用狀態(tài)模式會比原型模式更好。原型模式的缺點是在實現(xiàn)深層復(fù)制時需要編寫復(fù)雜的代碼。結(jié)構(gòu)型模式 適配器模式（Adapter Pattern） 適配器模式可以將一個類的接口和另一個類的接口匹配起來，使用的前提是你不能或不想修改原來的適配器母接口(adaptee)。例如，你向第三方購買了一些類、控件，但是沒有源程序，這時，使用適配器模式，你可以統(tǒng)一對象訪問接口。但客戶調(diào)用可能需要變動。橋接模式（Bridge Pattern） 橋接模式可以從接口中分離實現(xiàn)功能，使得設(shè)計更具擴展性，這樣，客戶調(diào)用方法時根本不需要知道實現(xiàn)的細節(jié)。 橋接模式減少了子類，假設(shè)程序要在2個操作系統(tǒng)中處理6種圖像格式，純粹的繼承就需要(2*6)12個子類，而應(yīng)用橋接模式，只需要(2+6)8個子類。它使得代碼更清潔，生成的執(zhí)行程序文件更小。　　 橋接模式的缺陷是抽象類與實現(xiàn)類的雙向連接使得運行速度減慢。組合模式（Composite Pattern） 組合模式可以清楚地定義分層次的復(fù)雜對象，表示對象的全部或部分層次，使得增加新部件也更容易，因為它讓客戶忽略了層次的不同性，而它的結(jié)構(gòu)又是動態(tài)的，提供了對象管理的靈活接口。組合模式對于樹結(jié)構(gòu)的控制有著神奇的功效，例如在人力資源系統(tǒng)的組織架構(gòu)及ERP系統(tǒng)的BOM設(shè)計中，組合模式得到重點應(yīng)用。 組合模式的缺陷是使得設(shè)計變得更加抽象。對象的商業(yè)規(guī)則如果很復(fù)雜，則實現(xiàn)組合模式具有很大挑戰(zhàn)性，并且，不是所有的方法都與葉部件子類有關(guān)聯(lián)。裝飾模式（Decorator Pattern） 裝飾模式提供了比靜態(tài)繼承更好的柔韌性，它允許開發(fā)一系列的功能類用來代替增加對象的行為，這既不會污染原來對象的源碼，還能使代碼更容易編寫，使類更具擴展性，因為變化都是由新的裝飾類來完成。還可以建立連接的裝飾對象關(guān)系鏈。 需要注意的是，裝飾鏈不宜過長。裝飾鏈太長會使系統(tǒng)花費較長時間用于初始化對象，同時信息在鏈中的傳遞也會浪費太多的時間。這個情況好比物品包裝，包了一層又一層，大包套小包。另外，如果原來的對象接口發(fā)生變化，它所以的裝飾類都要修改以匹配它的變化。派生子類會影響對象的內(nèi)部，而一個Decorator只會影響對象的外表。外觀模式（Fa?ade Pattern） 外觀模式提供了一個簡單且公用的接口去處理復(fù)雜的子系統(tǒng)，并且沒有減少子系統(tǒng)的功能。它遮蔽了子系統(tǒng)的復(fù)雜性，避免了客戶與子系統(tǒng)直接鏈接，它也減少了子系統(tǒng)與子系統(tǒng)間的連接，每個子系統(tǒng)都有它的Facade模式，每個子系統(tǒng)采用Facade模式去訪問其他子系統(tǒng)。外觀模式的劣勢就是限制了客戶的自由，減少了可變性。享元模式（Flyweight Pattern） Flyweight模式需要你認真考慮如何能細化對象，以減少處理的對象數(shù)量，從而減少存留對象在內(nèi)存或其他存儲設(shè)備中的占用量。然而，此模式需要維護大量對象的外部狀態(tài)，如果外部狀態(tài)的數(shù)據(jù)量大，傳遞、查找、計算這些惡數(shù)據(jù)會變得非常復(fù)雜。當(dāng)外部和內(nèi)部的狀態(tài)很難分清時，不宜采用flyweight模式。代理模式（Proxy Pattern） 當(dāng)對象在遠程機器上，要通過網(wǎng)絡(luò)來生成時，速度可能會慢，此時應(yīng)用Remote Proxy模式，可以掩蔽對象由網(wǎng)絡(luò)生成的過程，系統(tǒng)的速度會加快；對于大圖片的加載，Virtual Proxy模式可以讓加載在后臺進行，前臺用的Proxy對象使得整體運行速度得到優(yōu)化；Protect Proxy可以驗證對真實對象的引用權(quán)限。 代理模式的缺陷是請求的處理速度會變慢，并且實現(xiàn)Proxy模式需要額外的工作。行為型模式 職責(zé)鏈模式（Chain of Responsibility） 責(zé)任鏈模式可以減少對象的連接，為對象責(zé)任分配增加了很大的靈活性。該模式允許把一組類作為一個類來使用，并且在類的組合中，一個類的事件可以發(fā)送到另一個類并由其處理。 責(zé)任鏈模式通常應(yīng)用與圖形用戶界面中，窗體的部件可能會包含其他幾個小部件，就如同Windows窗體應(yīng)用程序中，控件中又可以放置其他控件，控件邊界會決定是否處理事件，或者將事件傳遞給父控件來處理。 另外，責(zé)任鏈還會以樹狀出現(xiàn)，這樣，一個事件可以傳給多個類，或者，多個類的信息可以提交到一個類。樹狀責(zé)任鏈能夠提供更靈活的技巧，但缺點是信息在樹中容易迷失。命令模式（Command Pattern） 命令模式分離了接受請求的對象與實現(xiàn)處理請求工作的對象，這樣，已經(jīng)存在的類可以保持不變，使得增加新類的工作更簡單。例如，很多軟件的宏命令就提高了系統(tǒng)的自動化程度。 命令模式還可以分離用戶界面和業(yè)務(wù)對象，降低系統(tǒng)的耦合度。 但是，命令模式最主要的缺陷就是，類的數(shù)量增加了，系統(tǒng)變得更復(fù)雜，程序的調(diào)試工作也相應(yīng)變得困難。解釋器模式（Interpreter Pattern） 解釋器模式的作用很強大，它使得改變和擴展文法變得容易，實現(xiàn)文法也變得簡單明了，很多編譯器，包括文本編輯器、網(wǎng)頁瀏覽器及VRML都應(yīng)用解釋器模式。 解釋器模式的缺陷就是，因為文句會分析成樹結(jié)構(gòu)，解釋器需要遞歸訪問它，所以效率會受影響。這種情況開發(fā)人員會有所體會，編譯整個工程源碼耗費時間都比較長。模版方法模式（Template Method） 模版方法模式在一個類中形式化地定義算法，而由它的子類實現(xiàn)細節(jié)的處理。模版方法模式的優(yōu)勢是，在子類定義處理算法時不會改變算法的結(jié)構(gòu)。 模版方法的特點在于，每個不同的實現(xiàn)都需要定義一個子類，這也復(fù)合高內(nèi)聚的責(zé)任分配模式，不能說成是它的缺點。迭代器模式（Iterator Pattern） 迭代器模式支持在聚集中移動游標，使得訪問聚合中的元素變得簡單，簡化了聚集的接口，封裝了聚合的對象。 迭代器模式還可以應(yīng)用于對樹結(jié)構(gòu)的訪問，程序不需要從頭逐行代碼查找相應(yīng)位置，可控制到從子集開始查找，對于加快程序的運行速度有很重要的作用。 迭代器模式的缺點是聚合密切相關(guān)，增加了耦合。但將這種耦合定義在抽象基類，可解決這個問題。觀察者模式（Oberver Pattern） 觀察者模式抽象了被觀察對象與觀察者對象的連接，提供了廣播式的對象間通信，并且容易增加新的觀察者對象。觀察者模式的缺陷是對象間的關(guān)系難以理解，在某種情況下會表現(xiàn)低效能。中介者模式（Mediator Pattern） 中介者模式分離了兩個同事類，簡化了對象協(xié)議，中央控制對象交互，從而使個體對象變得更容易且更簡單，因為它不需要傳遞數(shù)據(jù)給其他個體對象，僅僅傳給中介者就可以了。個體對象不需要具有處理內(nèi)部交流的邏輯，所以更加突出它的面向?qū)ο筇匦浴渫浤Ｊ?#xff08;Memento Pattern） Memento模式保存了封裝的邊界，一個Memento對象是另一種原發(fā)器對象的表示，不會被其他代碼改動。這種模式簡化了原發(fā)器對象，Memento只保存原發(fā)器的狀態(tài)。采用堆棧備忘對象，可以實現(xiàn)多次取消操作。狀態(tài)模式（State Pattern） 狀態(tài)模式在對象內(nèi)保存特定的狀態(tài)并且就不同的狀態(tài)履行不同的行為，它使?fàn)顟B(tài)的變化顯得清晰明了，也很容易創(chuàng)建對象的新狀態(tài)。 狀態(tài)模式在工作流或游戲等各種系統(tǒng)中大量使用，例如在政府OA系統(tǒng)中，一個批文的狀態(tài)有多種：未辦、正在處理、正在批示、正在審核和已經(jīng)完成等各種狀態(tài)。在網(wǎng)絡(luò)游戲中，一個游戲活動存在開始、開玩、正在玩、輸贏等各種狀態(tài)。使用狀態(tài)模式就可以實現(xiàn)游戲狀態(tài)的總控，而游戲狀態(tài)決定了游戲的各個方面。策略模式（Strategy Pattern） 策略模式提供了替代派生的子類，并定義類的每個行為，剔除了代碼中條件的判斷語句，使得擴展和結(jié)合新的行為變得更容易，根本不需要變動應(yīng)用程序。策略模式可以避免使用多重條件轉(zhuǎn)移語句，系統(tǒng)變得更新靈活。應(yīng)用策略模式會產(chǎn)生很多子類，這符合高內(nèi)聚的責(zé)任分配模式。訪問者模式（Visitor Pattern） Visitor(訪問者)模式使得增加新的操作變得容易，它可以收集有關(guān)聯(lián)的方法，而分離沒有關(guān)聯(lián)的方法，特別適用于分離因為不同原因而變化的事物，如“在男人中分離出男孩”。但Visitor模式常常要打破對象的封裝性，visitor與element需要達成某些共識。

?

轉(zhuǎn)載于:https://www.cnblogs.com/kangshuai/p/4712260.html

總結(jié)

以上是生活随笔為你收集整理的c#中的23种设计模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。