|
創(chuàng)建型模式 工廠方法（Factory Method） 在工廠方法模式中，工廠方法用來創(chuàng)建客戶所需要的產(chǎn)品，同時(shí)還向客戶隱藏了哪種具體產(chǎn)品類將被實(shí)例化這一細(xì)節(jié)。工廠方法模式的核心是一個(gè)抽象工廠類，各種具體工廠類通過抽象工廠類將工廠方法繼承下來。如此使得客戶可以只關(guān)心抽象產(chǎn)品和抽象工廠，完全不用理會(huì)返回的是哪一種具體產(chǎn)品，也不用關(guān)系它是如何被具體工廠創(chuàng)建的。 抽象工廠模式（Abstract Factory） 抽象工廠模式的主要優(yōu)點(diǎn)是隔離了具體類的生成，使得客戶不需要知道什么被創(chuàng)建了。猶豫這種隔離，更換一個(gè)具體工廠就變得相對(duì)容易。所有的具體工廠都實(shí)現(xiàn)了抽象工廠中定義的那些公共接口，因此只需改變具體工廠的實(shí)例，就可以在某種程度上改變這個(gè)軟件的系統(tǒng)的行為。另外，應(yīng)用抽象工廠模式符合GRASP純虛構(gòu)的模式，可以實(shí)現(xiàn)高內(nèi)聚低耦合的設(shè)計(jì)目的，因此抽象工廠模式得到了廣泛應(yīng)用。 建造者模式（Builder Pattern） 建造者模式將一個(gè)復(fù)雜對(duì)象的生成責(zé)任作了很好的分配。它把構(gòu)造過程放在指揮者的方法中，把裝配過程放到具體建造者類中。建造者模式的產(chǎn)品之間都有共通點(diǎn)，但有時(shí)候，產(chǎn)品之間的差異性很大，這就需要借助工廠方法模式或抽象工廠模式。另外，如果產(chǎn)品的內(nèi)部變化復(fù)雜，Builder的每一個(gè)子類都需要對(duì)應(yīng)到不同的產(chǎn)品去做構(gòu)建的動(dòng)作、方法，這就需要定義很多個(gè)具體建造類來實(shí)現(xiàn)這種變化。 單件模式（Single Pattern） Singleton單例模式為一個(gè)面向?qū)ο蟮膽?yīng)用程序提供了對(duì)象唯一的訪問點(diǎn)，不管它實(shí)現(xiàn)何種功能，此種模式都為設(shè)計(jì)及開發(fā)團(tuán)隊(duì)提供了共享的概念。然而，Singleton對(duì)象類派生子類就有很大的困難，只有在父類沒有被實(shí)例化時(shí)才可以實(shí)現(xiàn)。值得注意的是，有些對(duì)象不可以做成Singleton，比如.net的數(shù)據(jù)庫鏈接對(duì)象(Connection)，整個(gè)應(yīng)用程序同享一個(gè)Connection對(duì)象會(huì)出現(xiàn)連接池溢出錯(cuò)誤。另外，.net提供了自動(dòng)廢物回收的技術(shù)，因此，如果實(shí)例化的對(duì)象長時(shí)間不被利用，系統(tǒng)會(huì)認(rèn)為它是廢物，自動(dòng)消滅它并回收它的資源，下次利用時(shí)又會(huì)重新實(shí)例化，這種情況下應(yīng)注意其狀態(tài)的丟失。 原型模式（Protype Pattern） 原型模式得到了廣泛的應(yīng)用，特別是在創(chuàng)建對(duì)象成本較大的情況下(初始化需占用較長時(shí)間，占用太多CPU資源或網(wǎng)絡(luò)資源。比如通過Webservice或DCOM創(chuàng)建對(duì)象，或者創(chuàng)建對(duì)象要裝載大文件)，系統(tǒng)如果需要重復(fù)利用，新的對(duì)象可以通過原型模式對(duì)已有對(duì)象的屬性進(jìn)行復(fù)制并稍作修改來取得。另外，如果系統(tǒng)要保存對(duì)象的狀態(tài)而對(duì)象的狀態(tài)變化很小，或者對(duì)象本身占內(nèi)存不大的時(shí)候，也可以用原型模式配合備忘錄模式來應(yīng)用。相反地，如果對(duì)象的狀態(tài)變化很大，或者對(duì)象占用內(nèi)存很大，那么采用狀態(tài)模式會(huì)比原型模式更好。原型模式的缺點(diǎn)是在實(shí)現(xiàn)深層復(fù)制時(shí)需要編寫復(fù)雜的代碼。 結(jié)構(gòu)型模式 適配器模式（Adapter Pattern） 適配器模式可以將一個(gè)類的接口和另一個(gè)類的接口匹配起來，使用的前提是你不能或不想修改原來的適配器母接口(adaptee)。例如，你向第三方購買了一些類、控件，但是沒有源程序，這時(shí)，使用適配器模式，你可以統(tǒng)一對(duì)象訪問接口。但客戶調(diào)用可能需要變動(dòng)。 橋接模式（Bridge Pattern） 橋接模式可以從接口中分離實(shí)現(xiàn)功能，使得設(shè)計(jì)更具擴(kuò)展性，這樣，客戶調(diào)用方法時(shí)根本不需要知道實(shí)現(xiàn)的細(xì)節(jié)。 橋接模式減少了子類，假設(shè)程序要在2個(gè)操作系統(tǒng)中處理6種圖像格式，純粹的繼承就需要(2*6)12個(gè)子類，而應(yīng)用橋接模式，只需要(2+6)8個(gè)子類。它使得代碼更清潔，生成的執(zhí)行程序文件更小?！ ?br>橋接模式的缺陷是抽象類與實(shí)現(xiàn)類的雙向連接使得運(yùn)行速度減慢。 組合模式（Composite Pattern） 組合模式可以清楚地定義分層次的復(fù)雜對(duì)象，表示對(duì)象的全部或部分層次，使得增加新部件也更容易，因?yàn)樗尶蛻艉雎粤藢哟蔚牟煌裕慕Y(jié)構(gòu)又是動(dòng)態(tài)的，提供了對(duì)象管理的靈活接口。組合模式對(duì)于樹結(jié)構(gòu)的控制有著神奇的功效，例如在人力資源系統(tǒng)的組織架構(gòu)及ERP系統(tǒng)的BOM設(shè)計(jì)中，組合模式得到重點(diǎn)應(yīng)用。 組合模式的缺陷是使得設(shè)計(jì)變得更加抽象。對(duì)象的商業(yè)規(guī)則如果很復(fù)雜，則實(shí)現(xiàn)組合模式具有很大挑戰(zhàn)性，并且，不是所有的方法都與葉部件子類有關(guān)聯(lián)。 裝飾模式（Decorator Pattern） 裝飾模式提供了比靜態(tài)繼承更好的柔韌性，它允許開發(fā)一系列的功能類用來代替增加對(duì)象的行為，這既不會(huì)污染原來對(duì)象的源碼，還能使代碼更容易編寫，使類更具擴(kuò)展性，因?yàn)樽兓际怯尚碌难b飾類來完成。還可以建立連接的裝飾對(duì)象關(guān)系鏈。 需要注意的是，裝飾鏈不宜過長。裝飾鏈太長會(huì)使系統(tǒng)花費(fèi)較長時(shí)間用于初始化對(duì)象，同時(shí)信息在鏈中的傳遞也會(huì)浪費(fèi)太多的時(shí)間。這個(gè)情況好比物品包裝，包了一層又一層，大包套小包。另外，如果原來的對(duì)象接口發(fā)生變化，它所以的裝飾類都要修改以匹配它的變化。派生子類會(huì)影響對(duì)象的內(nèi)部，而一個(gè)Decorator只會(huì)影響對(duì)象的外表。 外觀模式（Fa?ade Pattern） |
|
|
