第8章 創(chuàng)建型設(shè)計(jì)模式

第8章創(chuàng)建型設(shè)計(jì)模式《軟件體系結(jié)構(gòu)與設(shè)計(jì)實(shí)用教程》第二版創(chuàng)建型模式創(chuàng)建型模式概述創(chuàng)建型模式(CreationalPattern)對(duì)類的實(shí)例化過(guò)程進(jìn)行了抽象，能夠?qū)④浖K中對(duì)象的創(chuàng)建和對(duì)象的使用分離。為了使軟件的結(jié)構(gòu)更加清晰，外界對(duì)于這些對(duì)象只需要知道它們共同的接口，而不清楚其具體的實(shí)現(xiàn)細(xì)節(jié)，使整個(gè)系統(tǒng)的設(shè)計(jì)更加符合單一職責(zé)原則。創(chuàng)建型模式創(chuàng)建型模式概述創(chuàng)建型模式在創(chuàng)建什么(What)，由誰(shuí)創(chuàng)建(Who)，何時(shí)創(chuàng)建(When)等方面都為軟件設(shè)計(jì)者提供了盡可能大的靈活性。創(chuàng)建型模式隱藏了類的實(shí)例的創(chuàng)建細(xì)節(jié)，通過(guò)隱藏對(duì)象如何被創(chuàng)建和組合在一起達(dá)到使整個(gè)系統(tǒng)獨(dú)立的目的。創(chuàng)建型模式簡(jiǎn)單工廠模式（SimpleFactory）工廠方法模式（FactoryMethod）抽象工廠模式（AbstractFactory）建造者模式（Builder）原型模式（Prototype）單例模式（Singleton）創(chuàng)建型模式簡(jiǎn)介8.1簡(jiǎn)單工廠模式模式動(dòng)機(jī)考慮一個(gè)簡(jiǎn)單的軟件應(yīng)用場(chǎng)景，一個(gè)軟件系統(tǒng)可以提供多個(gè)外觀不同的按鈕（如圓形按鈕、矩形按鈕、菱形按鈕等），這些按鈕都源自同一個(gè)基類，不過(guò)在繼承基類后不同的子類修改了部分屬性從而使得它們可以呈現(xiàn)不同的外觀，如果我們希望在使用這些按鈕時(shí)，不需要知道這些具體按鈕類的名字，只需要知道表示該按鈕類的一個(gè)參數(shù)，并提供一個(gè)調(diào)用方便的方法，把該參數(shù)傳入方法即可返回一個(gè)相應(yīng)的按鈕對(duì)象，此時(shí)，就可以使用簡(jiǎn)單工廠模式。簡(jiǎn)單工廠模式模式定義簡(jiǎn)單工廠模式(SimpleFactoryPattern)：又稱為靜態(tài)工廠方法(StaticFactoryMethod)模式，它屬于類創(chuàng)建型模式。在簡(jiǎn)單工廠模式中，可以根據(jù)參數(shù)的不同返回不同類的實(shí)例。簡(jiǎn)單工廠模式專門(mén)定義一個(gè)類來(lái)負(fù)責(zé)創(chuàng)建其他類的實(shí)例，被創(chuàng)建的實(shí)例通常都具有共同的父類。簡(jiǎn)單工廠模式模式結(jié)構(gòu)簡(jiǎn)單工廠模式模式結(jié)構(gòu)簡(jiǎn)單工廠模式包含如下角色：Factory：工廠角色Product：抽象產(chǎn)品角色ConcreteProduct：具體產(chǎn)品角色簡(jiǎn)單工廠模式模式分析將對(duì)象的創(chuàng)建和對(duì)象本身業(yè)務(wù)處理分離可以降低系統(tǒng)的耦合度，使得兩者修改起來(lái)都相對(duì)容易。在調(diào)用工廠類的工廠方法時(shí)，由于工廠方法是靜態(tài)方法，使用起來(lái)很方便，可通過(guò)類名直接調(diào)用，而且只需要傳入一個(gè)簡(jiǎn)單的參數(shù)即可，在實(shí)際開(kāi)發(fā)中，還可以在調(diào)用時(shí)將所傳入的參數(shù)保存在XML等格式的配置文件中，修改參數(shù)時(shí)無(wú)須修改任何Java源代碼。簡(jiǎn)單工廠模式最大的問(wèn)題在于工廠類的職責(zé)相對(duì)過(guò)重，增加新的產(chǎn)品需要修改工廠類的判斷邏輯，這一點(diǎn)與開(kāi)閉原則是相違背的。簡(jiǎn)單工廠模式的要點(diǎn)在于：當(dāng)你需要什么，只需要傳入一個(gè)正確的參數(shù)，就可以獲取你所需要的對(duì)象，而無(wú)須知道其創(chuàng)建細(xì)節(jié)。簡(jiǎn)單工廠模式模式優(yōu)缺點(diǎn)簡(jiǎn)單工廠模式的優(yōu)點(diǎn)工廠類含有必要的判斷邏輯，可以決定在什么時(shí)候創(chuàng)建哪一個(gè)產(chǎn)品類的實(shí)例，客戶端可以免除直接創(chuàng)建產(chǎn)品對(duì)象的責(zé)任，而僅僅“消費(fèi)”產(chǎn)品；簡(jiǎn)單工廠模式通過(guò)這種做法實(shí)現(xiàn)了對(duì)責(zé)任的分割，它提供了專門(mén)的工廠類用于創(chuàng)建對(duì)象。客戶端無(wú)須知道所創(chuàng)建的具體產(chǎn)品類的類名，只需要知道具體產(chǎn)品類所對(duì)應(yīng)的參數(shù)即可，對(duì)于一些復(fù)雜的類名，通過(guò)簡(jiǎn)單工廠模式可以減少使用者的記憶量。通過(guò)引入配置文件，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產(chǎn)品類，在一定程度上提高了系統(tǒng)的靈活性。簡(jiǎn)單工廠模式模式優(yōu)缺點(diǎn)簡(jiǎn)單工廠模式的缺點(diǎn)由于工廠類集中了所有產(chǎn)品創(chuàng)建邏輯，一旦不能正常工作，整個(gè)系統(tǒng)都要受到影響。使用簡(jiǎn)單工廠模式將會(huì)增加系統(tǒng)中類的個(gè)數(shù)，在一定程序上增加了系統(tǒng)的復(fù)雜度和理解難度。系統(tǒng)擴(kuò)展困難，一旦添加新產(chǎn)品就不得不修改工廠邏輯，在產(chǎn)品類型較多時(shí)，有可能造成工廠邏輯過(guò)于復(fù)雜，不利于系統(tǒng)的擴(kuò)展和維護(hù)。簡(jiǎn)單工廠模式由于使用了靜態(tài)工廠方法，造成工廠角色無(wú)法形成基于繼承的等級(jí)結(jié)構(gòu)。簡(jiǎn)單工廠模式模式適用環(huán)境在以下情況下可以使用簡(jiǎn)單工廠模式：工廠類負(fù)責(zé)創(chuàng)建的對(duì)象比較少：由于創(chuàng)建的對(duì)象較少，不會(huì)造成工廠方法中的業(yè)務(wù)邏輯太過(guò)復(fù)雜?？蛻舳酥恢纻魅牍S類的參數(shù)，對(duì)于如何創(chuàng)建對(duì)象不關(guān)心：客戶端既不需要關(guān)心創(chuàng)建細(xì)節(jié)，甚至連類名都不需要記住，只需要知道類型所對(duì)應(yīng)的參數(shù)。8.2工廠方法模式簡(jiǎn)單工廠模式的不足在簡(jiǎn)單工廠模式中，只提供了一個(gè)工廠類，該工廠類處于對(duì)產(chǎn)品類進(jìn)行實(shí)例化的中心位置，它知道每一個(gè)產(chǎn)品對(duì)象的創(chuàng)建細(xì)節(jié)，并決定何時(shí)實(shí)例化哪一個(gè)產(chǎn)品類。簡(jiǎn)單工廠模式最大的缺點(diǎn)是當(dāng)有新產(chǎn)品要加入到系統(tǒng)中時(shí)，必須修改工廠類，加入必要的處理邏輯，這違背了“開(kāi)閉原則”。在簡(jiǎn)單工廠模式中，所有的產(chǎn)品都是由同一個(gè)工廠創(chuàng)建，工廠類職責(zé)較重，業(yè)務(wù)邏輯較為復(fù)雜，具體產(chǎn)品與工廠類之間的耦合度高，嚴(yán)重影響了系統(tǒng)的靈活性和擴(kuò)展性，而工廠方法模式則可以很好地解決這一問(wèn)題。工廠方法模式模式動(dòng)機(jī)現(xiàn)在對(duì)該系統(tǒng)進(jìn)行修改，不再設(shè)計(jì)一個(gè)按鈕工廠類來(lái)統(tǒng)一負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，而是將具體按鈕的創(chuàng)建過(guò)程交給專門(mén)的工廠子類去完成，我們先定義一個(gè)抽象的按鈕工廠類，再定義具體的工廠類來(lái)生成圓形按鈕、矩形按鈕、菱形按鈕等，它們實(shí)現(xiàn)在抽象按鈕工廠類中定義的方法。這種抽象化的結(jié)果使這種結(jié)構(gòu)可以在不修改具體工廠類的情況下引進(jìn)新的產(chǎn)品，如果出現(xiàn)新的按鈕類型，只需要為這種新類型的按鈕創(chuàng)建一個(gè)具體的工廠類就可以獲得該新按鈕的實(shí)例，這一特點(diǎn)無(wú)疑使得工廠方法模式具有超越簡(jiǎn)單工廠模式的優(yōu)越性，更加符合“開(kāi)閉原則”。工廠方法模式模式定義工廠方法模式(FactoryMethodPattern)又稱為工廠模式，也叫虛擬構(gòu)造器(VirtualConstructor)模式或者多態(tài)工廠(PolymorphicFactory)模式，它屬于類創(chuàng)建型模式。在工廠方法模式中，工廠父類負(fù)責(zé)定義創(chuàng)建產(chǎn)品對(duì)象的公共接口，而工廠子類則負(fù)責(zé)生成具體的產(chǎn)品對(duì)象，這樣做的目的是將產(chǎn)品類的實(shí)例化操作延遲到工廠子類中完成，即通過(guò)工廠子類來(lái)確定究竟應(yīng)該實(shí)例化哪一個(gè)具體產(chǎn)品類。工廠方法模式模式結(jié)構(gòu)工廠方法模式模式結(jié)構(gòu)工廠方法模式包含如下角色：Product：抽象產(chǎn)品ConcreteProduct：具體產(chǎn)品Factory：抽象工廠ConcreteFactory：具體工廠工廠方法模式模式分析工廠方法模式是簡(jiǎn)單工廠模式的進(jìn)一步抽象和推廣。由于使用了面向?qū)ο蟮亩鄳B(tài)性，工廠方法模式保持了簡(jiǎn)單工廠模式的優(yōu)點(diǎn)，而且克服了它的缺點(diǎn)。在工廠方法模式中，核心的工廠類不再負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，而是將具體創(chuàng)建工作交給子類去做。這個(gè)核心類僅僅負(fù)責(zé)給出具體工廠必須實(shí)現(xiàn)的接口，而不負(fù)責(zé)哪一個(gè)產(chǎn)品類被實(shí)例化這種細(xì)節(jié)，這使得工廠方法模式可以允許系統(tǒng)在不修改工廠角色的情況下引進(jìn)新產(chǎn)品。

工廠方法模式模式分析當(dāng)系統(tǒng)擴(kuò)展需要添加新的產(chǎn)品對(duì)象時(shí)，僅僅需要添加一個(gè)具體產(chǎn)品對(duì)象以及一個(gè)具體工廠對(duì)象，原有工廠對(duì)象不需要進(jìn)行任何修改，也不需要修改客戶端，很好地符合了“開(kāi)閉原則”。而簡(jiǎn)單工廠模式在添加新產(chǎn)品對(duì)象后不得不修改工廠方法，擴(kuò)展性不好。工廠方法模式退化后可以演變成簡(jiǎn)單工廠模式。工廠方法模式模式優(yōu)缺點(diǎn)工廠方法模式的優(yōu)點(diǎn)在工廠方法模式中，工廠方法用來(lái)創(chuàng)建客戶所需要的產(chǎn)品，同時(shí)還向客戶隱藏了哪種具體產(chǎn)品類將被實(shí)例化這一細(xì)節(jié)，用戶只需要關(guān)心所需產(chǎn)品對(duì)應(yīng)的工廠，無(wú)須關(guān)心創(chuàng)建細(xì)節(jié)，甚至無(wú)須知道具體產(chǎn)品類的類名。基于工廠角色和產(chǎn)品角色的多態(tài)性設(shè)計(jì)是工廠方法模式的關(guān)鍵。它能夠使工廠可以自主確定創(chuàng)建何種產(chǎn)品對(duì)象，而如何創(chuàng)建這個(gè)對(duì)象的細(xì)節(jié)則完全封裝在具體工廠內(nèi)部。工廠方法模式之所以又被稱為多態(tài)工廠模式，是因?yàn)樗械木唧w工廠類都具有同一抽象父類。使用工廠方法模式的另一個(gè)優(yōu)點(diǎn)是在系統(tǒng)中加入新產(chǎn)品時(shí)，無(wú)須修改抽象工廠和抽象產(chǎn)品提供的接口，無(wú)須修改客戶端，也無(wú)須修改其他的具體工廠和具體產(chǎn)品，而只要添加一個(gè)具體工廠和具體產(chǎn)品就可以了。這樣，系統(tǒng)的可擴(kuò)展性也就變得非常好，完全符合“開(kāi)閉原則”。工廠方法模式模式優(yōu)缺點(diǎn)工廠方法模式的缺點(diǎn)在添加新產(chǎn)品時(shí)，需要編寫(xiě)新的具體產(chǎn)品類，而且還要提供與之對(duì)應(yīng)的具體工廠類，系統(tǒng)中類的個(gè)數(shù)將成對(duì)增加，在一定程度上增加了系統(tǒng)的復(fù)雜度，有更多的類需要編譯和運(yùn)行，會(huì)給系統(tǒng)帶來(lái)一些額外的開(kāi)銷。由于考慮到系統(tǒng)的可擴(kuò)展性，需要引入抽象層，在客戶端代碼中均使用抽象層進(jìn)行定義，增加了系統(tǒng)的抽象性和理解難度，且在實(shí)現(xiàn)時(shí)可能需要用到DOM、反射等技術(shù)，增加了系統(tǒng)的實(shí)現(xiàn)難度。工廠方法模式模式適用環(huán)境在以下情況下可以使用工廠方法模式：一個(gè)類不知道它所需要的對(duì)象的類：在工廠方法模式中，客戶端不需要知道具體產(chǎn)品類的類名，只需要知道所對(duì)應(yīng)的工廠即可，具體的產(chǎn)品對(duì)象由具體工廠類創(chuàng)建；客戶端需要知道創(chuàng)建具體產(chǎn)品的工廠類。一個(gè)類通過(guò)其子類來(lái)指定創(chuàng)建哪個(gè)對(duì)象：在工廠方法模式中，對(duì)于抽象工廠類只需要提供一個(gè)創(chuàng)建產(chǎn)品的接口，而由其子類來(lái)確定具體要?jiǎng)?chuàng)建的對(duì)象，利用面向?qū)ο蟮亩鄳B(tài)性和里氏代換原則，在程序運(yùn)行時(shí)，子類對(duì)象將覆蓋父類對(duì)象，從而使得系統(tǒng)更容易擴(kuò)展。將創(chuàng)建對(duì)象的任務(wù)委托給多個(gè)工廠子類中的某一個(gè)，客戶端在使用時(shí)可以無(wú)須關(guān)心是哪一個(gè)工廠子類創(chuàng)建產(chǎn)品子類，需要時(shí)再動(dòng)態(tài)指定，可將具體工廠類的類名存儲(chǔ)在配置文件或數(shù)據(jù)庫(kù)中。8.3抽象工廠模式模式動(dòng)機(jī)在工廠方法模式中具體工廠負(fù)責(zé)生產(chǎn)具體的產(chǎn)品，每一個(gè)具體工廠對(duì)應(yīng)一種具體產(chǎn)品，工廠方法也具有唯一性，一般情況下，一個(gè)具體工廠中只有一個(gè)工廠方法或者一組重載的工廠方法。但是有時(shí)候我們需要一個(gè)工廠可以提供多個(gè)產(chǎn)品對(duì)象，而不是單一的產(chǎn)品對(duì)象。抽象工廠模式模式動(dòng)機(jī)為了更清晰地理解工廠方法模式，需要先引入兩個(gè)概念：產(chǎn)品等級(jí)結(jié)構(gòu)：產(chǎn)品等級(jí)結(jié)構(gòu)即產(chǎn)品的繼承結(jié)構(gòu)，如一個(gè)抽象類是電視機(jī)，其子類有海爾電視機(jī)、海信電視機(jī)、TCL電視機(jī)，則抽象電視機(jī)與具體品牌的電視機(jī)之間構(gòu)成了一個(gè)產(chǎn)品等級(jí)結(jié)構(gòu)，抽象電視機(jī)是父類，而具體品牌的電視機(jī)是其子類。產(chǎn)品族：在抽象工廠模式中，產(chǎn)品族是指由同一個(gè)工廠生產(chǎn)的，位于不同產(chǎn)品等級(jí)結(jié)構(gòu)中的一組產(chǎn)品，如海爾電器工廠生產(chǎn)的海爾電視機(jī)、海爾電冰箱，海爾電視機(jī)位于電視機(jī)產(chǎn)品等級(jí)結(jié)構(gòu)中，海爾電冰箱位于電冰箱產(chǎn)品等級(jí)結(jié)構(gòu)中。抽象工廠模式模式動(dòng)機(jī)產(chǎn)品族與產(chǎn)品等級(jí)結(jié)構(gòu)示意圖

抽象工廠模式模式動(dòng)機(jī)當(dāng)系統(tǒng)所提供的工廠所需生產(chǎn)的具體產(chǎn)品并不是一個(gè)簡(jiǎn)單的對(duì)象，而是多個(gè)位于不同產(chǎn)品等級(jí)結(jié)構(gòu)中屬于不同類型的具體產(chǎn)品時(shí)需要使用抽象工廠模式。抽象工廠模式是所有形式的工廠模式中最為抽象和最具一般性的一種形態(tài)。抽象工廠模式與工廠方法模式最大的區(qū)別在于，工廠方法模式針對(duì)的是一個(gè)產(chǎn)品等級(jí)結(jié)構(gòu)，而抽象工廠模式則需要面對(duì)多個(gè)產(chǎn)品等級(jí)結(jié)構(gòu)，一個(gè)工廠等級(jí)結(jié)構(gòu)可以負(fù)責(zé)多個(gè)不同產(chǎn)品等級(jí)結(jié)構(gòu)中的產(chǎn)品對(duì)象的創(chuàng)建。當(dāng)一個(gè)工廠等級(jí)結(jié)構(gòu)可以創(chuàng)建出分屬于不同產(chǎn)品等級(jí)結(jié)構(gòu)的一個(gè)產(chǎn)品族中的所有對(duì)象時(shí)，抽象工廠模式比工廠方法模式更為簡(jiǎn)單、有效率。抽象工廠模式模式定義

抽象工廠模式(AbstractFactoryPattern)：提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無(wú)須指定它們具體的類。抽象工廠模式又稱為Kit模式，屬于對(duì)象創(chuàng)建型模式。抽象工廠模式模式結(jié)構(gòu)抽象工廠模式模式結(jié)構(gòu)抽象工廠模式包含如下角色：AbstractFactory：抽象工廠ConcreteFactory：具體工廠AbstractProduct：抽象產(chǎn)品Product：具體產(chǎn)品抽象工廠模式模式分析抽象工廠類的典型代碼如下：publicabstractclassAbstractFactory{publicabstractAbstractProductAcreateProductA();publicabstractAbstractProductBcreateProductB();}抽象工廠模式模式分析具體工廠類的典型代碼如下：publicclassConcreteFactory1extendsAbstractFactory{publicAbstractProductAcreateProductA(){returnnewConcreteProductA1();}publicAbstractProductBcreateProductB(){returnnewConcreteProductB1();}}抽象工廠模式模式優(yōu)缺點(diǎn)抽象工廠模式的優(yōu)點(diǎn)抽象工廠模式隔離了具體類的生成，使得客戶并不需要知道什么被創(chuàng)建。由于這種隔離，更換一個(gè)具體工廠就變得相對(duì)容易。所有的具體工廠都實(shí)現(xiàn)了抽象工廠中定義的那些公共接口，因此只需改變具體工廠的實(shí)例，就可以在某種程度上改變整個(gè)軟件系統(tǒng)的行為。另外，應(yīng)用抽象工廠模式可以實(shí)現(xiàn)高內(nèi)聚低耦合的設(shè)計(jì)目的，因此抽象工廠模式得到了廣泛的應(yīng)用。當(dāng)一個(gè)產(chǎn)品族中的多個(gè)對(duì)象被設(shè)計(jì)成一起工作時(shí)，它能夠保證客戶端始終只使用同一個(gè)產(chǎn)品族中的對(duì)象。這對(duì)一些需要根據(jù)當(dāng)前環(huán)境來(lái)決定其行為的軟件系統(tǒng)來(lái)說(shuō)，是一種非常實(shí)用的設(shè)計(jì)模式。增加新的具體工廠和產(chǎn)品族很方便，無(wú)須修改已有系統(tǒng)，符合“開(kāi)閉原則”。抽象工廠模式模式優(yōu)缺點(diǎn)抽象工廠模式的缺點(diǎn)在添加新的產(chǎn)品對(duì)象時(shí)，難以擴(kuò)展抽象工廠來(lái)生產(chǎn)新種類的產(chǎn)品，這是因?yàn)樵诔橄蠊S角色中規(guī)定了所有可能被創(chuàng)建的產(chǎn)品集合，要支持新種類的產(chǎn)品就意味著要對(duì)該接口進(jìn)行擴(kuò)展，而這將涉及到對(duì)抽象工廠角色及其所有子類的修改，顯然會(huì)帶來(lái)較大的不便。開(kāi)閉原則的傾斜性（增加新的工廠和產(chǎn)品族容易，增加新的產(chǎn)品等級(jí)結(jié)構(gòu)麻煩）抽象工廠模式模式適用環(huán)境在以下情況下可以使用抽象工廠模式：一個(gè)系統(tǒng)不應(yīng)當(dāng)依賴于產(chǎn)品類實(shí)例如何被創(chuàng)建、組合和表達(dá)的細(xì)節(jié)，這對(duì)于所有類型的工廠模式都是重要的。系統(tǒng)中有多于一個(gè)的產(chǎn)品族，而每次只使用其中某一產(chǎn)品族。屬于同一個(gè)產(chǎn)品族的產(chǎn)品將在一起使用，這一約束必須在系統(tǒng)的設(shè)計(jì)中體現(xiàn)出來(lái)。系統(tǒng)提供一個(gè)產(chǎn)品類的庫(kù)，所有的產(chǎn)品以同樣的接口出現(xiàn)，從而使客戶端不依賴于具體實(shí)現(xiàn)。8.4單例模式模式動(dòng)機(jī)對(duì)于系統(tǒng)中的某些類來(lái)說(shuō)，只有一個(gè)實(shí)例很重要，例如，一個(gè)系統(tǒng)中可以存在多個(gè)打印任務(wù)，但是只能有一個(gè)正在工作的任務(wù)；一個(gè)系統(tǒng)只能有一個(gè)窗口管理器或文件系統(tǒng)；一個(gè)系統(tǒng)只能有一個(gè)計(jì)時(shí)工具或ID（序號(hào)）生成器。單例模式模式動(dòng)機(jī)如何保證一個(gè)類只有一個(gè)實(shí)例并且這個(gè)實(shí)例易于被訪問(wèn)呢？定義一個(gè)全局變量可以確保對(duì)象隨時(shí)都可以被訪問(wèn)，但不能防止我們實(shí)例化多個(gè)對(duì)象。一個(gè)更好的解決辦法是讓類自身負(fù)責(zé)保存它的唯一實(shí)例。這個(gè)類可以保證沒(méi)有其他實(shí)例被創(chuàng)建，并且它可以提供一個(gè)訪問(wèn)該實(shí)例的方法。這就是單例模式的模式動(dòng)機(jī)。單例模式模式定義單例模式(SingletonPattern)：?jiǎn)卫Ｊ酱_保某一個(gè)類只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例，這個(gè)類稱為單例類，它提供全局訪問(wèn)的方法。單例模式的要點(diǎn)有三個(gè)：一是某個(gè)類只能有一個(gè)實(shí)例；二是它必須自行創(chuàng)建這個(gè)實(shí)例；三是它必須自行向整個(gè)系統(tǒng)提供這個(gè)實(shí)例。單例模式是一種對(duì)象創(chuàng)建型模式。單例模式又名單件模式或單態(tài)模式。單例模式模式結(jié)構(gòu)單例模式模式結(jié)構(gòu)單例模式包含如下角色：Singleton：?jiǎn)卫龁卫Ｊ侥Ｊ椒治鰡卫Ｊ降哪康氖潜ＷC一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問(wèn)它的全局訪問(wèn)點(diǎn)。單例模式包含的角色只有一個(gè)，就是單例類——Singleton。單例類擁有一個(gè)私有構(gòu)造函數(shù)，確保用戶無(wú)法通過(guò)new關(guān)鍵字直接實(shí)例化它。除此之外，該模式中包含一個(gè)靜態(tài)私有成員變量與靜態(tài)公有的工廠方法，該工廠方法負(fù)責(zé)檢驗(yàn)實(shí)例的存在性并實(shí)例化自己，然后存儲(chǔ)在靜態(tài)成員變量中，以確保只有一個(gè)實(shí)例被創(chuàng)建。單例模式模式分析單例模式的實(shí)現(xiàn)代碼如下所示：publicclassSingleton{ privatestaticSingletoninstance=null;//靜態(tài)私有成員變量

//私有構(gòu)造函數(shù)

privateSingleton() { }

//靜態(tài)公有工廠方法，返回唯一實(shí)例

publicstaticSingletongetInstance() { if(instance==null) instance=newSingleton(); returninstance; }}單例模式模式分析在單例模式的實(shí)現(xiàn)過(guò)程中，需要注意如下三點(diǎn)：?jiǎn)卫惖臉?gòu)造函數(shù)為私有；提供一個(gè)自身的靜態(tài)私有成員變量；提供一個(gè)公有的靜態(tài)工廠方法。單例模式模式優(yōu)缺點(diǎn)單例模式的優(yōu)點(diǎn)提供了對(duì)唯一實(shí)例的受控訪問(wèn)。因?yàn)閱卫惙庋b了它的唯一實(shí)例，所以它可以嚴(yán)格控制客戶怎樣以及何時(shí)訪問(wèn)它，并為設(shè)計(jì)及開(kāi)發(fā)團(tuán)隊(duì)提供了共享的概念。由于在系統(tǒng)內(nèi)存中只存在一個(gè)對(duì)象，因此可以節(jié)約系統(tǒng)資源，對(duì)于一些需要頻繁創(chuàng)建和銷毀的對(duì)象，單例模式無(wú)疑可以提高系統(tǒng)的性能。允許可變數(shù)目的實(shí)例。我們可以基于單例模式進(jìn)行擴(kuò)展，使用與單例控制相似的方法來(lái)獲得指定個(gè)數(shù)的對(duì)象實(shí)例。單例模式模式優(yōu)缺點(diǎn)單例模式的缺點(diǎn)由于單例模式中沒(méi)有抽象層，因此單例類的擴(kuò)展有很大的困難。單例類的職責(zé)過(guò)重，在一定程度上違背了“單一職責(zé)原則”。因?yàn)閱卫惣瘸洚?dāng)了工廠角色，提供了工廠方法，同時(shí)又充當(dāng)了產(chǎn)品角色，包含一些業(yè)務(wù)方法，將產(chǎn)品的創(chuàng)建和產(chǎn)品的本身的功能融合到一起。濫用單例將帶來(lái)一些負(fù)面問(wèn)題，如為了節(jié)省資源將數(shù)據(jù)庫(kù)連接池對(duì)象設(shè)計(jì)為單例類，可能會(huì)導(dǎo)致共享連接池對(duì)象的程序過(guò)多而出現(xiàn)連接池溢出；現(xiàn)在很多面向?qū)ο笳Z(yǔ)言(如Java、C#)的運(yùn)行環(huán)境都提供了自動(dòng)垃圾回收的技術(shù)，因此，如果實(shí)例化的對(duì)象長(zhǎng)時(shí)間不被利用，系統(tǒng)會(huì)認(rèn)為它是垃圾，會(huì)自動(dòng)銷毀并回收資源，下次利用時(shí)又將重新實(shí)例化，這將導(dǎo)致對(duì)象狀態(tài)的丟失。單例模式模式適用環(huán)境在以下情況下可以使用單例模式：系統(tǒng)只需要一個(gè)實(shí)例對(duì)象，如系統(tǒng)要求提供一個(gè)唯一的序列號(hào)生成器，或者需要考慮資源消耗太大而只允許創(chuàng)建一個(gè)對(duì)象?？蛻粽{(diào)用類的單個(gè)實(shí)例只允許使用一個(gè)公共訪問(wèn)點(diǎn)，除了該公共訪問(wèn)點(diǎn)，不能通過(guò)其他途徑訪問(wèn)該實(shí)例。在一個(gè)系統(tǒng)中要求一個(gè)類只有一個(gè)實(shí)例時(shí)才應(yīng)當(dāng)使用單例模式。反過(guò)來(lái)，如果一個(gè)類可以有幾個(gè)實(shí)例共存，就需要對(duì)單例模式進(jìn)行改進(jìn)，使之成為多例模式。8.5原型模式模式動(dòng)機(jī)在面向?qū)ο笙到y(tǒng)中，使用原型模式來(lái)復(fù)制一個(gè)對(duì)象自身，從而克隆出多個(gè)與原型對(duì)象一模一樣的對(duì)象。在軟件系統(tǒng)中，有些對(duì)象的創(chuàng)建過(guò)程較為復(fù)雜，而且有時(shí)候需要頻繁創(chuàng)建，原型模式通過(guò)給出一個(gè)原型對(duì)象來(lái)指明所要?jiǎng)?chuàng)建的對(duì)象的類型，然后用復(fù)制這個(gè)原型對(duì)象的辦法創(chuàng)建出更多同類型的對(duì)象，這就是原型模式的意圖所在。原型模式模式定義原型模式(PrototypePattern)：原型模式是一種對(duì)象創(chuàng)建型模式，用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并且通過(guò)復(fù)制這些原型創(chuàng)建新的對(duì)象。原型模式允許一個(gè)對(duì)象再創(chuàng)建另外一個(gè)可定制的對(duì)象，無(wú)須知道任何創(chuàng)建的細(xì)節(jié)。原型模式的基本工作原理是通過(guò)將一個(gè)原型對(duì)象傳給那個(gè)要發(fā)動(dòng)創(chuàng)建的對(duì)象，這個(gè)要發(fā)動(dòng)創(chuàng)建的對(duì)象通過(guò)請(qǐng)求原型對(duì)象拷貝原型自己來(lái)實(shí)現(xiàn)創(chuàng)建過(guò)程。原型模式模式結(jié)構(gòu)原型模式模式結(jié)構(gòu)原型模式包含如下角色：Prototype：抽象原型類ConcretePrototype：具體原型類Client：客戶類原型模式模式分析在原型模式結(jié)構(gòu)中定義了一個(gè)抽象原型類，所有的Java類都繼承自java.lang.Object，而Object類提供一個(gè)clone()方法，可以將一個(gè)Java對(duì)象復(fù)制一份。因此在Java中可以直接使用Object提供的clone()方法來(lái)實(shí)現(xiàn)對(duì)象的克隆，Java語(yǔ)言中的原型模式實(shí)現(xiàn)很簡(jiǎn)單。能夠?qū)崿F(xiàn)克隆的Java類必須實(shí)現(xiàn)一個(gè)標(biāo)識(shí)接口Cloneable，表示這個(gè)Java類支持復(fù)制。如果一個(gè)類沒(méi)有實(shí)現(xiàn)這個(gè)接口但是調(diào)用了clone()方法，Java編譯器將拋出一個(gè)CloneNotSupportedException異常。原型模式模式分析示例代碼：publicclassPrototypeDemoimplementsCloneable{

……

publicObjectclone()

{

Objectobject=null;

try{

object=super.clone();

}catch(CloneNotSupportedExceptionexception){

System.err.println("Notsupportcloneable");

}

returnobject;}……}原型模式模式分析通常情況下，一個(gè)類包含一些成員對(duì)象，在使用原型模式克隆對(duì)象時(shí)，根據(jù)其成員對(duì)象是否也克隆，原型模式可以分為兩種形式：深克隆和淺克隆。原型模式模式分析淺克隆與深克隆深克隆淺克隆原型模式模式分析Java語(yǔ)言提供的clone()方法將對(duì)象復(fù)制了一份并返回給調(diào)用者。一般而言，clone()方法滿足：(1)對(duì)任何的對(duì)象x，都有x.clone()!=x，即克隆對(duì)象與原對(duì)象不是同一個(gè)對(duì)象。(2)對(duì)任何的對(duì)象x，都有x.clone().getClass()==x.getClass()，即克隆對(duì)象與原對(duì)象的類型一樣。(3)如果對(duì)象x的equals()方法定義恰當(dāng)，那么x.clone().equals(x)應(yīng)該成立。原型模式模式優(yōu)缺點(diǎn)原型模式的優(yōu)點(diǎn)當(dāng)創(chuàng)建新的對(duì)象實(shí)例較為復(fù)雜時(shí)，使用原型模式可以簡(jiǎn)化對(duì)象的創(chuàng)建過(guò)程，通過(guò)一個(gè)已有實(shí)例可以提高新實(shí)例的創(chuàng)建效率?？梢詣?dòng)態(tài)增加或減少產(chǎn)品類。原型模式提供了簡(jiǎn)化的創(chuàng)建結(jié)構(gòu)。可以使用深克隆的方式保存對(duì)象的狀態(tài)。原型模式模式優(yōu)缺點(diǎn)原型模式的缺點(diǎn)需要為每一個(gè)類配備一個(gè)克隆方法，而且這個(gè)克隆方法需要對(duì)類的功能進(jìn)行通盤(pán)考慮，這對(duì)全新的類來(lái)說(shuō)不是很難，但對(duì)已有的類進(jìn)行改造時(shí)，不一定是件容易的事，必須修改其源代碼，違背了“開(kāi)閉原則”。在實(shí)現(xiàn)深克隆時(shí)需要編寫(xiě)較為復(fù)雜的代碼。原型模式模式適用環(huán)境在以下情況下可以使用原型模式：創(chuàng)建新對(duì)象成本較大，新的對(duì)象可以通過(guò)原型模式對(duì)已有對(duì)象進(jìn)行復(fù)制來(lái)獲得，如果是相似對(duì)象，則可以對(duì)其屬性稍作修改。如果系統(tǒng)要保存對(duì)象的狀態(tài)，而對(duì)象的狀態(tài)變化很小，或者對(duì)象本身占內(nèi)存不大的時(shí)候，也可以使用原型模式配合備忘錄模式來(lái)應(yīng)用。相反，如果對(duì)象的狀態(tài)變化很大，或者對(duì)象占用的內(nèi)存很大，那么采用狀態(tài)模式會(huì)比原型模式更好。需要避免使用分層次的工廠類來(lái)創(chuàng)建分層次的對(duì)象，并且類的實(shí)例對(duì)象只有一個(gè)或很少的幾個(gè)組合狀態(tài)，通過(guò)復(fù)制原型對(duì)象得到新實(shí)例可能比使用構(gòu)造函數(shù)創(chuàng)建一個(gè)新實(shí)例更加方便。8.6建造者模式模式動(dòng)機(jī)無(wú)論是在現(xiàn)實(shí)世界中還是在軟件系統(tǒng)中，都存在一些復(fù)雜的對(duì)象，它們擁有多個(gè)組成部分，如汽車，它包括車輪、方向盤(pán)、發(fā)送機(jī)等各種部件。而對(duì)于大多數(shù)用戶而言，無(wú)須知道這些部件的裝配細(xì)節(jié)，也幾乎不會(huì)使用單獨(dú)某個(gè)部件，而是使用一輛完整的汽車，可以通過(guò)建造者模式對(duì)其進(jìn)行設(shè)計(jì)與描述，建造者模式可以將部件和其組裝過(guò)程分開(kāi)，一步一步創(chuàng)建一個(gè)復(fù)雜的對(duì)象。用戶只需要指定復(fù)雜對(duì)象的類型就可以得到該對(duì)象，而無(wú)須知道其內(nèi)部的具體構(gòu)造細(xì)節(jié)。建造者模式模式動(dòng)機(jī)在軟件開(kāi)發(fā)中，也存在大量類似汽車一樣的復(fù)雜對(duì)象，它們擁有一系列成員屬性，這些成員屬性中有些是引用類型的成員對(duì)象。而且在這些復(fù)雜對(duì)象中，還可能存在一些限制條件，如某些屬性沒(méi)有賦值則復(fù)雜對(duì)象不能作為一個(gè)完整的產(chǎn)品使用；有些屬性的賦值必須按照某個(gè)順序，一個(gè)屬性沒(méi)有賦值之前，另一個(gè)屬性可能無(wú)法賦值等。復(fù)雜對(duì)象相當(dāng)于一輛有待建造的汽車，而對(duì)象的屬性相當(dāng)于汽車的部件，建造產(chǎn)品的過(guò)程就相當(dāng)于組合部件的過(guò)程。由于組合部件的過(guò)程很復(fù)雜，因此，這些部件的組合過(guò)程往往被“外部化”到一個(gè)稱作建造者的對(duì)象里，建造者返還給客戶端的是一個(gè)已經(jīng)建造完畢的完整產(chǎn)品對(duì)象，而用戶無(wú)須關(guān)心該對(duì)象所包含的屬性以及它們的組裝方式，這就是建造者模式的模式動(dòng)機(jī)。建造者模式模式定義建造者模式(BuilderPattern)：將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。建造者模式是一步一步創(chuàng)建一個(gè)復(fù)雜的對(duì)象，它允許用戶只通過(guò)指定復(fù)雜對(duì)象的類型和內(nèi)容就可以構(gòu)建它們，用戶不需要知道內(nèi)部的具體構(gòu)建細(xì)節(jié)。建造者模式屬于對(duì)象創(chuàng)建型模式。根據(jù)中文翻譯的不同，建造者模式又可以稱為生成器模式。建造者模式模式結(jié)構(gòu)建造者模式模式結(jié)構(gòu)建造者模式包含如下角色：Builder：抽象建造者ConcreteBuilder：具體建造者Director：指揮者Product：產(chǎn)品角色建造者模式模式分析一個(gè)典型的復(fù)雜對(duì)象其類代碼示例如下：publicclassProduct{ privateStringpartA;//可以是任意類型

privateStringpartB; privateStringpartC; //partA的Getter方法和Setter方法省略

//partB的Getter方法和Setter方法省略

//partC的Getter方法和Setter方法省略}建造者模式模式分析抽象建造者類中定義了產(chǎn)品的創(chuàng)建方法和返回方法，其典型代碼如下：publicabstractclassBuilder{ protectedProductproduct=newProduct();

publicabstractvoidbuildPartA(); publicabstractvoidbuildPartB(); publicabstractvoidbuildPartC();

publicProductgetResult() { returnproduct; }}建造者模式模式分析建造者模式的結(jié)構(gòu)中還引入了一個(gè)指揮者類Director，該類的作用主要有兩個(gè)：一方面它隔離了客戶與生產(chǎn)過(guò)程；另一方面它負(fù)責(zé)控制產(chǎn)品的生成過(guò)程。指揮者針對(duì)抽象建造者編程，客戶端只需要知道具體建造者的類型，即可通過(guò)指揮者類調(diào)用建造者的相關(guān)方法，返回一個(gè)完整的產(chǎn)品對(duì)象。

建造者模式模式分析指揮者類的代碼示例如下：publicclassDirector{ privateBuilderbuilder;

publicDirector(Builderbuilder) { this.builder=builder; }

publicvoidsetBuilder(Builderbuilder) { this.builder=builer; }

publicProductconstruct() { builder.buildPartA(); builder.buildPartB(); builder.buildPartC(); returnbuilder.getResult(); }}建造者模式模式分析客戶端類代碼片段：