軟件設(shè)計(jì)原則與模式-基于Java-Python語(yǔ)言實(shí)現(xiàn)（微課版）課件 第二章 創(chuàng)建模式

第二章創(chuàng)建模式(CreativnalPattem)創(chuàng)建模式(CreativnalPattem)創(chuàng)建型模式抽象了實(shí)例化過(guò)程。該模式幫助一個(gè)系統(tǒng)如何獨(dú)立創(chuàng)建、組合和表示他的那些對(duì)象。一些系統(tǒng)在創(chuàng)建對(duì)象時(shí)，需要?jiǎng)討B(tài)地決定怎樣創(chuàng)建對(duì)象，創(chuàng)建哪些對(duì)象，如何組合和表示這些對(duì)象。創(chuàng)建模式描述了怎樣構(gòu)造和封裝這些動(dòng)態(tài)的決定。創(chuàng)建模式分為類(lèi)的創(chuàng)建模式和對(duì)象的創(chuàng)建模式兩種。類(lèi)創(chuàng)建型模式使用繼承改變被實(shí)例化的類(lèi)。對(duì)象創(chuàng)建型模式將實(shí)例化委托給另一個(gè)對(duì)象。創(chuàng)建模式包括：工廠模式第一節(jié)簡(jiǎn)單工廠模式第二節(jié)工廠方法模式第三節(jié)抽象工廠模式第四節(jié)單例模式第五節(jié)多例模式第六節(jié)建造模式第七節(jié)原型模式工廠模式工廠模式專(zhuān)門(mén)負(fù)責(zé)將大量有共同接口的類(lèi)實(shí)例化。工廠模式可以動(dòng)態(tài)決定將哪一個(gè)類(lèi)實(shí)例化，不必事先知道每次要實(shí)例化哪一個(gè)類(lèi)。工廠模式有以下三種形態(tài)：簡(jiǎn)單工廠模式：又稱(chēng)靜態(tài)工廠方法模式。工廠方法模式：又稱(chēng)多態(tài)性工廠模式。抽象工廠模式：又稱(chēng)工具箱模式。第一節(jié) 簡(jiǎn)單工廠(SimpleFactory)模式簡(jiǎn)單工廠模式是類(lèi)的創(chuàng)建模式，又叫做靜態(tài)工廠方法（StaticFactoryMethod）模式。簡(jiǎn)單工廠模式是由一個(gè)工廠對(duì)象決定創(chuàng)建出哪一種產(chǎn)品類(lèi)的實(shí)例。簡(jiǎn)單工廠模式將客戶類(lèi)和工廠類(lèi)分開(kāi)?？蛻纛?lèi)對(duì)象任何時(shí)候需要某種產(chǎn)品，只需向工廠請(qǐng)求即可?？蛻纛?lèi)對(duì)象無(wú)須修改就可以接納新產(chǎn)品。缺點(diǎn)是當(dāng)產(chǎn)品修改時(shí)，工廠類(lèi)也要做相應(yīng)的修改。如:如何創(chuàng)建及如何向客戶端提供。實(shí)用案例：小型農(nóng)場(chǎng)系統(tǒng)例子：女?huà)z摶土造人話說(shuō)：“天地開(kāi)辟，未有人民，女?huà)z摶土為人?！迸?huà)z用土和八卦爐造出了大活人，但在女?huà)z造出人之前，人的概念只存在于女?huà)z的大腦里。女?huà)z造人，這就是簡(jiǎn)單工廠模式的應(yīng)用。程序結(jié)構(gòu)圖如圖所示。1.2 簡(jiǎn)單工廠模式的結(jié)構(gòu)簡(jiǎn)單工廠模式是根據(jù)傳入的參數(shù)來(lái)決定到底應(yīng)該創(chuàng)建那個(gè)類(lèi)的事例出來(lái)。下圖是簡(jiǎn)單工廠模式的一般結(jié)構(gòu)。由圖可以看出，簡(jiǎn)單工廠模式由工廠角色、抽象產(chǎn)品角色、產(chǎn)品角色這三部分組成。工廠角色（Creator）：這是工廠方法模式的核心，但客戶端調(diào)用他的工廠方法的時(shí)候，返回給客戶端的是產(chǎn)品角色的一個(gè)類(lèi)的對(duì)象實(shí)例。產(chǎn)品角色(ConcreteProduct)：簡(jiǎn)單工廠方法所創(chuàng)建的任何一個(gè)對(duì)象都是這個(gè)角色的一個(gè)類(lèi)的對(duì)象實(shí)例。抽象產(chǎn)品角色(Product)：定義了產(chǎn)品角色所共有的共性，通常由一個(gè)java接口或者是一個(gè)java抽象類(lèi)。如果具體產(chǎn)品之間沒(méi)有共同的商業(yè)邏輯，就用java接口，如果有共同的商業(yè)邏輯，就用一個(gè)java抽象類(lèi)。Python實(shí)現(xiàn)案例簡(jiǎn)單工廠模式的缺點(diǎn)是當(dāng)在產(chǎn)品角色中再增加一個(gè)類(lèi)的時(shí)候，工廠方法必須有發(fā)生相應(yīng)的改變，這就導(dǎo)致了擴(kuò)展性不符合開(kāi)-閉原則?！芭?huà)z造人”簡(jiǎn)單工廠模式的實(shí)現(xiàn):P23女?huà)z采用簡(jiǎn)單工廠模式成功造出了人，不過(guò)還沒(méi)有膚色和性別。

簡(jiǎn)單工廠模式使用實(shí)例簡(jiǎn)單工廠模式是在什么場(chǎng)景下使用呢，下面以登錄功能為例說(shuō)明：假如應(yīng)用系統(tǒng)需要支持多種登錄方式如：口令認(rèn)證、域認(rèn)證（口令認(rèn)證通常是去數(shù)據(jù)庫(kù)中驗(yàn)證用戶，而域認(rèn)證則是需要到微軟的域中驗(yàn)證用戶）。自然的做法就是建立一個(gè)各種登錄方式都適用的接口，如圖所示。代碼見(jiàn)書(shū)P25簡(jiǎn)單工廠模式的優(yōu)缺點(diǎn)1.3.1簡(jiǎn)單工廠模式的優(yōu)點(diǎn)模式的核心是工廠類(lèi)。這個(gè)類(lèi)含有必要的邏輯判斷，可以決定在什么時(shí)候創(chuàng)建哪一個(gè)登錄驗(yàn)證類(lèi)的實(shí)例，而調(diào)用者則可以免除直接創(chuàng)建對(duì)象的責(zé)任。簡(jiǎn)單工廠模式通過(guò)這種做法實(shí)現(xiàn)了對(duì)責(zé)任的分割，當(dāng)系統(tǒng)引入新的登錄方式的時(shí)候無(wú)需修改調(diào)用者。1.3.2簡(jiǎn)單工廠模式的缺點(diǎn)這個(gè)工廠類(lèi)集中了所有的創(chuàng)建邏輯，當(dāng)有復(fù)雜的多層次等級(jí)結(jié)構(gòu)時(shí)，所有的業(yè)務(wù)邏輯都在這個(gè)工廠類(lèi)中實(shí)現(xiàn)。什么時(shí)候它不能工作了，整個(gè)系統(tǒng)都會(huì)受到影響。練習(xí)：小型農(nóng)場(chǎng)系統(tǒng)實(shí)現(xiàn)有一個(gè)農(nóng)場(chǎng)公司，專(zhuān)門(mén)向市場(chǎng)銷(xiāo)售各類(lèi)水果，在這個(gè)系統(tǒng)里需要描述三種水果：葡萄（Grappe）、草莓（Stuawberry）、蘋(píng)果（Apple）。水果與其他植物不同，最終可以采摘食用，那么一個(gè)自然的做法是建立一個(gè)各種水果都適用的接口，以便與其他農(nóng)場(chǎng)里的植物區(qū)分開(kāi)來(lái)，UML類(lèi)圖設(shè)計(jì)如圖所示。代碼見(jiàn)書(shū)P27第二節(jié) 工廠方法（FactoryMethod）模式工廠方法模式:核心工廠類(lèi)不再負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，而是將具體創(chuàng)建的工作交給子類(lèi)去做，成為一個(gè)抽象工廠角色，僅負(fù)責(zé)給出具體工廠類(lèi)必須實(shí)現(xiàn)的接口，而不接觸哪一個(gè)產(chǎn)品類(lèi)應(yīng)當(dāng)被實(shí)例化這種細(xì)節(jié)。與簡(jiǎn)單工廠模式的區(qū)別：在工廠方法模式中，核心的工廠類(lèi)不再負(fù)責(zé)所有具體產(chǎn)品實(shí)例的創(chuàng)建，而僅僅是需要負(fù)責(zé)給出具體工廠子類(lèi)必須實(shí)現(xiàn)的接口，讓工廠子類(lèi)去負(fù)責(zé)具體產(chǎn)品實(shí)例的創(chuàng)建。例子：女?huà)z造有膚色人種話說(shuō)這天女?huà)z娘娘采集黃土捏成人的形狀，然后放到八卦爐中燒制，最后放置到大地上生長(zhǎng)，工藝過(guò)程是沒(méi)有錯(cuò)的，但是意外隨時(shí)都會(huì)發(fā)生：第一次烤泥人，嗞嗞嗞……，感覺(jué)應(yīng)該熟了，往大地上一放，哇，沒(méi)烤熟！于是一個(gè)白人誕生了?。ㄟ@也是缺乏經(jīng)驗(yàn)的最好證明）第二次烤泥人，這時(shí)盤(pán)古經(jīng)過(guò)，看見(jiàn)女?huà)z娘娘在此，便停下聊了會(huì)兒天。這天上一日，地上十年，聊著聊著不覺(jué)過(guò)了晌午，女?huà)z這才想起八卦爐里還燒著人呢，趕緊取出來(lái)放到世間一看，嘿，熟過(guò)頭了，于是黑人誕生了！第三次烤泥人，這次不敢大意了，一邊燒制一邊察看，直到表皮微黃，外焦里嫩。嘿，真正好，于是女?huà)z心中的偶像：黃色人種出現(xiàn)了！不過(guò)如果時(shí)間還是稍長(zhǎng)了一些的話，那可就是黃里透黑喲……?，F(xiàn)在對(duì)造人過(guò)程進(jìn)行分析，該過(guò)程涉及三個(gè)對(duì)象：女?huà)z、八卦爐、三種不同膚色的人，女?huà)z可以使用場(chǎng)景類(lèi)Client來(lái)表示，八卦爐類(lèi)似于一個(gè)工廠，負(fù)責(zé)制造生產(chǎn)產(chǎn)品（即人類(lèi)）：三種不同膚色的人，他們都是同一個(gè)接口下的不同實(shí)現(xiàn)類(lèi)，都是人嘛，只是膚色、語(yǔ)言不同，對(duì)于八卦爐來(lái)說(shuō)都是它生產(chǎn)出的產(chǎn)品。這個(gè)造人程序的UML結(jié)構(gòu)圖如圖所示。類(lèi)圖比較簡(jiǎn)單，AbstractHumanFactory是一個(gè)抽象類(lèi)，定義了一個(gè)八卦爐都具有的整體功能，八卦爐為實(shí)現(xiàn)類(lèi)，完成具體的任務(wù)：創(chuàng)建人類(lèi)；Human接口是人類(lèi)的總稱(chēng)，其三個(gè)實(shí)現(xiàn)類(lèi)分別為三類(lèi)人種；女?huà)z娘娘類(lèi)是一個(gè)場(chǎng)景類(lèi)，負(fù)責(zé)模擬這個(gè)場(chǎng)景，執(zhí)行相關(guān)的任務(wù)。代碼見(jiàn)書(shū)P352.1 工廠方法模式的結(jié)構(gòu)工廠方法模式的結(jié)構(gòu)如圖所示。從圖可以看出，這個(gè)使用了工廠方法模式的系統(tǒng)涉及到以下的角色：工廠方法模式結(jié)構(gòu)的示意性源代碼見(jiàn)書(shū)P33抽象工廠(Creator)角色：擔(dān)任這個(gè)角色的是工廠方法模式的核心，它是與應(yīng)用程序無(wú)關(guān)的。任何在模式中創(chuàng)建對(duì)象的工廠類(lèi)必須實(shí)現(xiàn)這個(gè)接口。這里，這個(gè)角色由接口Creator扮演；在實(shí)際的系統(tǒng)中，這個(gè)角色也經(jīng)常用抽象類(lèi)來(lái)實(shí)現(xiàn)。具體工廠(ConcreteCreator)角色：擔(dān)任這個(gè)角色的是實(shí)現(xiàn)了抽象工廠接口的具體Java類(lèi)。具體工廠角色含有與應(yīng)用密切相關(guān)的邏輯，并且受到應(yīng)用程序的調(diào)用以創(chuàng)建產(chǎn)品對(duì)象。這里給出了兩個(gè)這樣的角色，也就是具體Java類(lèi)Concretecreatorl和ConcreteCreatcr2。抽象產(chǎn)品(Product)角色：工廠方法模式所創(chuàng)建對(duì)象即產(chǎn)品對(duì)象的共同父類(lèi)或共同擁有的接口。這里這個(gè)角色為接口Product。具體產(chǎn)品(ConcreteProduct)角色：這個(gè)角色實(shí)現(xiàn)了抽象產(chǎn)品角色所聲明的接口。工廠方法模式所創(chuàng)建的每一個(gè)對(duì)象都是某個(gè)具體產(chǎn)品角色的實(shí)例。這里這個(gè)角色由具體類(lèi)ConcreteProductl和ConcreteProduct2扮演，它們都實(shí)現(xiàn)了Product接口。工廠方法模式的實(shí)際應(yīng)用導(dǎo)出功能有這么一個(gè)需求：XX系統(tǒng)需要支持對(duì)數(shù)據(jù)庫(kù)中的員工薪資進(jìn)行導(dǎo)出，并且支持多種格式如：HTML、CSV、PDF等，每種格式導(dǎo)出的結(jié)構(gòu)有所不同，比如：財(cái)務(wù)跟其他人對(duì)導(dǎo)出薪資的HTML格式要求可能會(huì)不一樣，因?yàn)樨?cái)務(wù)可能需要特定的格式方便核算或其他用途。如果使用簡(jiǎn)單工廠模式，則工廠類(lèi)必定過(guò)于臃腫。因?yàn)楹?jiǎn)單工廠模式只有一個(gè)工廠類(lèi)，它需要處理所有的創(chuàng)建的邏輯。假如以上需求暫時(shí)只支持3種導(dǎo)出的格式以及2種導(dǎo)出的結(jié)構(gòu)，那工廠類(lèi)則需要6個(gè)ifelse來(lái)創(chuàng)建6種不同的類(lèi)型。如果日后需求不斷增加，則后果不堪設(shè)想。這時(shí)就需要工廠方法模式來(lái)處理以上需求，下面作詳細(xì)說(shuō)明。前面的例子用工廠方法模式設(shè)計(jì)時(shí)，核心的工廠類(lèi)不再負(fù)責(zé)所有的對(duì)象的創(chuàng)建，而是將具體創(chuàng)建的工作交給子類(lèi)去做。這個(gè)核心類(lèi)則搖身一變，成為了一個(gè)抽象工廠角色，僅負(fù)責(zé)給出具體工廠子類(lèi)必須實(shí)現(xiàn)的接口，而不接觸哪一個(gè)類(lèi)應(yīng)當(dāng)被實(shí)例化這種細(xì)節(jié)。這種進(jìn)一步抽象化的結(jié)果，使這種工廠方法模式可以用來(lái)允許系統(tǒng)在不修改具體工廠角色的情況下引進(jìn)新的產(chǎn)品，這一特點(diǎn)無(wú)疑使得工廠方法模式具有超過(guò)簡(jiǎn)單工廠模式的優(yōu)越性。針對(duì)以上需求設(shè)計(jì)的UML圖如圖所示。源代碼見(jiàn)書(shū)P38抽象工廠（ExportFactory）角色：是工廠方法模式核心，任何在模式中創(chuàng)建對(duì)象的工廠類(lèi)必須實(shí)現(xiàn)這個(gè)接口。這個(gè)角色也常用抽象類(lèi)實(shí)現(xiàn)。具體工廠（ExportHtmlFactory、ExportPdfFactory）角色：實(shí)現(xiàn)了抽象工廠接口的具體JAVA類(lèi)。含有與業(yè)務(wù)密切相關(guān)的邏輯，并受使用者調(diào)用以創(chuàng)建導(dǎo)出類(lèi)（如：ExportStandardHtmlFile）。抽象導(dǎo)出（ExportFile）角色：工廠方法模式所創(chuàng)建對(duì)象的超類(lèi)，是所有導(dǎo)出類(lèi)的共同父類(lèi)或共同擁有的接口。這個(gè)角色也常用抽象類(lèi)實(shí)現(xiàn)。具體導(dǎo)出（ExportStandardHtmlFile等）角色：實(shí)現(xiàn)了抽象導(dǎo)出（ExportFile）角色所聲明的接口，工廠方法模式所創(chuàng)建的每一個(gè)對(duì)象都是某個(gè)具體導(dǎo)出角色的實(shí)例。UML圖結(jié)構(gòu)分析練習(xí)：工廠方法模式在農(nóng)場(chǎng)系統(tǒng)中的實(shí)現(xiàn)

系統(tǒng)優(yōu)化現(xiàn)在繼續(xù)考察農(nóng)場(chǎng)的管理系統(tǒng)。在本書(shū)的“簡(jiǎn)單工廠模式”一章里，討論了支持水果類(lèi)作物的系統(tǒng)。在那個(gè)系統(tǒng)中，有一個(gè)全知全能的園丁角色(FriutGardaner)，控制所有作物的種植、生長(zhǎng)和收獲?，F(xiàn)在這個(gè)農(nóng)場(chǎng)的規(guī)模變大了，而同時(shí)發(fā)生的是管理更加專(zhuān)業(yè)化了。過(guò)去的全能人物沒(méi)有了，每一種農(nóng)作物都有專(zhuān)門(mén)的園丁管理，形成規(guī)?；蛯?zhuān)業(yè)化生產(chǎn)。系統(tǒng)設(shè)計(jì)取代了過(guò)去的全能角色的是一個(gè)抽象的園丁角色，這個(gè)角色規(guī)定出具體園丁角色需要實(shí)現(xiàn)的具體職能，而真正負(fù)責(zé)作物管理的則是負(fù)責(zé)各種作物的具體園丁角色。這一章仍然考慮前面所討論過(guò)的植物，包括葡萄(Grape)、草莓(Stmwberry)以及蘋(píng)果(Apple)等。專(zhuān)業(yè)化的管理要求有專(zhuān)門(mén)的園丁負(fù)責(zé)專(zhuān)門(mén)的水果，比如蘋(píng)果由“蘋(píng)果園丁”負(fù)責(zé)，草莓有“草莓園丁”負(fù)責(zé)，而葡萄由“葡萄園丁”負(fù)責(zé)。這些“蘋(píng)果園丁”、“草莓園丁”以及“葡萄園丁”都是實(shí)現(xiàn)了抽象的“水果園丁”接口的具體工廠類(lèi)，而“水果園丁”則扮演抽象工廠角色。農(nóng)場(chǎng)系統(tǒng)的設(shè)計(jì)圖就如圖所示。源代碼請(qǐng)見(jiàn)配套電子版。第三節(jié) 抽象工廠（AbstractFactoryPattern）模式抽象工廠模式定義：為創(chuàng)建一組相關(guān)或相互依賴(lài)的對(duì)象提供一個(gè)接口，而且無(wú)需指定他們的具體類(lèi)。每個(gè)模式都是針對(duì)一定問(wèn)題的解決方案。抽象工廠模式面對(duì)的問(wèn)題是多產(chǎn)品等級(jí)結(jié)構(gòu)的系統(tǒng)設(shè)計(jì)。抽象工廠模式的用意：抽象工廠模式可以向客戶端提供一個(gè)接口，使客戶端在不必指定產(chǎn)品具體類(lèi)型的情況下，創(chuàng)建多個(gè)產(chǎn)品族中的產(chǎn)品對(duì)象。抽象工廠模式的起源抽象工廠模式的起源于用于創(chuàng)建分屬于不同操作系統(tǒng)的視窗構(gòu)件。如：命令按鍵（Button）與文字框（Text)都是視窗構(gòu)件，在UNIX操作系統(tǒng)的視窗環(huán)境和Windows操作系統(tǒng)的視窗環(huán)境中，這兩個(gè)構(gòu)件有不同的本地實(shí)現(xiàn)，它們的細(xì)節(jié)有所不同。在學(xué)習(xí)抽象工廠具體實(shí)例之前，應(yīng)先明白兩個(gè)重要的概念：產(chǎn)品族和產(chǎn)品等級(jí)結(jié)構(gòu)。產(chǎn)品族windowsLinux按鈕按鈕文本框文本框產(chǎn)品等級(jí)結(jié)構(gòu)產(chǎn)品族：是指位于不同產(chǎn)品等級(jí)結(jié)構(gòu)中功能相關(guān)聯(lián)的產(chǎn)品組成的家族。抽象工廠模式所提供的一系列產(chǎn)品就組成一個(gè)產(chǎn)品族。如windows和Linux操作系統(tǒng)就是兩個(gè)不同的產(chǎn)品族。產(chǎn)品等級(jí)結(jié)構(gòu)：工廠方法提供的一系列產(chǎn)品稱(chēng)為一個(gè)等級(jí)結(jié)構(gòu)。windows和Linux操作系統(tǒng)中的“按鈕”、“文本框”等分別為一個(gè)產(chǎn)品等級(jí)結(jié)構(gòu)不同產(chǎn)品等級(jí)結(jié)構(gòu)產(chǎn)品對(duì)象的創(chuàng)建。工廠方法模式和抽象工廠模式的區(qū)別：如果工廠的產(chǎn)品全部屬于同一個(gè)等級(jí)結(jié)構(gòu)，則屬于工廠方法模式；如果工廠的產(chǎn)品來(lái)自多個(gè)等級(jí)結(jié)構(gòu)，則屬于抽象工廠模式。一般情況下，產(chǎn)品族和產(chǎn)品等級(jí)結(jié)構(gòu)的關(guān)系如圖所示。例子：女?huà)z造有性別人種話說(shuō)女?huà)z每日里采集黃土捏成人的形狀，然后放到八卦爐中燒制，最后放置到大地上生長(zhǎng)，這活做多了，也是辛苦萬(wàn)分。那日這天便想到了一條妙計(jì)：把繩子攪到泥水里，然后把沾滿泥水的繩子憑空一甩，甩出的泥點(diǎn)便是那人的形狀，然后放到八卦爐中燒制，最后放置到大地上生長(zhǎng)。這效率那是提高了不知多少倍，要不咱這地球哪來(lái)70億人。女?huà)z造萬(wàn)物系統(tǒng)里分陰、陽(yáng)兩個(gè)產(chǎn)品族,分別對(duì)應(yīng)兩條繩：陰繩和陽(yáng)繩，陰繩造出的是女人，陽(yáng)繩造出的是男人。這男女人還都分為黑人、白人和黃種人。讀者可以看出，女蝸造物用的是抽象工廠模式。女?huà)z造萬(wàn)物系統(tǒng)里產(chǎn)品等級(jí)結(jié)構(gòu)的“產(chǎn)品”有兩個(gè)劃分方法:一是按照“產(chǎn)品”是黑人、白人和黃種人來(lái)劃分，二是按照“產(chǎn)品”是男女、來(lái)劃分。女?huà)z的繩子按照陰、陽(yáng)劃分，產(chǎn)品則按照是黑人、白人和黃種人劃分。女?huà)z造萬(wàn)物系統(tǒng)里分陰、陽(yáng)兩個(gè)產(chǎn)品族和黑人、白人和黃種人三個(gè)產(chǎn)品等級(jí)結(jié)構(gòu)的類(lèi)圖如圖所示。3.1 抽象工廠模式的結(jié)構(gòu)采用抽象工廠模式設(shè)計(jì)出的系統(tǒng)結(jié)構(gòu)圖如所示。從圖可以看出，抽象工廠模式涉及到以下的角色。抽象工廠模式的結(jié)構(gòu)抽象工廠模式涉及到以下的角色抽象工廠角色具體工廠類(lèi)角色抽象產(chǎn)品角色具體產(chǎn)品角色抽象工廠模式系統(tǒng)結(jié)構(gòu)圖抽象工廠角色：是工廠方法模式的核心，與應(yīng)用系統(tǒng)的商業(yè)邏輯無(wú)關(guān)。用Java接口或抽象Java類(lèi)實(shí)現(xiàn)。具體工廠類(lèi)角色：該角色直接在客戶端調(diào)用下創(chuàng)建產(chǎn)品的實(shí)例。該角色含有選擇合適的產(chǎn)品對(duì)象的邏輯，這個(gè)邏輯是應(yīng)用系統(tǒng)的商業(yè)邏輯緊密相關(guān)。抽象產(chǎn)品角色：是工廠方法模式所創(chuàng)建的對(duì)象的父類(lèi)。通常使用Java接口或者抽象Java類(lèi)實(shí)現(xiàn)這一角色。具體產(chǎn)品角色：抽象工廠模式所創(chuàng)建的任何產(chǎn)品對(duì)象都是某一個(gè)具體產(chǎn)品類(lèi)的實(shí)例。這是客戶端最終需要的東西，其內(nèi)部一定充滿了應(yīng)用系統(tǒng)的商業(yè)邏輯?！芭?huà)z造人”抽象工廠模式實(shí)現(xiàn)

抽象產(chǎn)品(AbstractProduct)角色，由Human、黑色人種、白色人種、黃色人種組成。具體產(chǎn)品(ConcreteProduct)角色由男性黑色人種、男性白色人種、男性黃色人種、女性黑色人種、女性白色人種、女性黃色人種組成。抽象工廠(AbstractFactory)角色由AbstractHumanFactory組成。具體工廠類(lèi)(ConcreteFactory)角色由陰繩、陽(yáng)繩組成。女蝸造物抽象工廠模式UML結(jié)構(gòu)圖3.4 抽象工廠的優(yōu)缺點(diǎn)：優(yōu)點(diǎn)分離接口和實(shí)現(xiàn)客戶端使用抽象工廠來(lái)創(chuàng)建需要的對(duì)象，而客戶端根本就不知道具體的實(shí)現(xiàn)是誰(shuí)，客戶端只是面向產(chǎn)品的接口編程而已。也就是說(shuō)，客戶端從具體的產(chǎn)品實(shí)現(xiàn)中解耦。使切換產(chǎn)品族變得容易因?yàn)橐粋€(gè)具體的工廠實(shí)現(xiàn)代表的是一個(gè)產(chǎn)品族，比如上面例子的從windows系列到Linux系列只需要切換一下具體工廠。缺點(diǎn)不太容易擴(kuò)展新的產(chǎn)品如果需要給整個(gè)產(chǎn)品族添加一個(gè)新的產(chǎn)品，那么就需要修改抽象工廠，這樣就會(huì)導(dǎo)致修改所有的工廠實(shí)現(xiàn)類(lèi)。抽象工廠模式的示意性源代碼P45練習(xí)：抽象工廠模式在農(nóng)場(chǎng)中的實(shí)現(xiàn)第四節(jié) 單例（Singleton）模式單例模式屬于對(duì)象模式單例模式:單例模式確保某一個(gè)類(lèi)只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例單例模式。單例模式只應(yīng)在有真正的“單一實(shí)例”的需求時(shí)才可使用。實(shí)用案例Windows操作系統(tǒng)都有一個(gè)回收站，回收站自行提供自己的實(shí)例，在整個(gè)系統(tǒng)中該回收站只能有一個(gè)實(shí)例，整個(gè)系統(tǒng)都使用這個(gè)惟一的實(shí)例。因此回收站是單例模式的應(yīng)用。打印機(jī)管理程序也是單例模式的應(yīng)用。4.1 單例模式的結(jié)構(gòu)單例模式的特點(diǎn)：?jiǎn)卫?lèi)只能有一個(gè)實(shí)例。單例類(lèi)必須自己創(chuàng)建自己的唯一實(shí)例。單例類(lèi)必須給所有其他對(duì)象提供這一實(shí)例。4.2 單例模式的類(lèi)型單例模式分為三種類(lèi)型：餓漢式、懶漢式和登記式。下面分別討論。4.2.1 餓漢式單例模式餓漢式指全局的單例實(shí)例在類(lèi)裝載時(shí)構(gòu)建并初始化。優(yōu)點(diǎn)是速度快，不調(diào)用時(shí)也創(chuàng)建，餓漢式單例類(lèi)被加載時(shí)，靜態(tài)變量instance會(huì)被初始化，此時(shí)類(lèi)的私有構(gòu)造函數(shù)會(huì)被調(diào)用。餓漢式其實(shí)是一種比較形象的稱(chēng)謂。既然餓，那么在創(chuàng)建對(duì)象實(shí)例的時(shí)候就比較著急，餓了嘛，于是在裝載類(lèi)的時(shí)候就創(chuàng)建對(duì)象實(shí)例。餓漢式是典型的空間換時(shí)間，當(dāng)類(lèi)裝載的時(shí)候就會(huì)創(chuàng)建類(lèi)的實(shí)例，不管你用不用，先創(chuàng)建出來(lái)，然后每次調(diào)用的時(shí)候，就不需要再判斷，節(jié)省了運(yùn)行時(shí)間。餓漢式單例模式的實(shí)現(xiàn)4.2.2 懶漢式單例模式1懶漢式單例介紹懶漢式：指全局的單例實(shí)例在第一次被使用時(shí)構(gòu)建。延遲初始化。速度慢，調(diào)用時(shí)才創(chuàng)建。懶漢式其實(shí)是一種比較形象的稱(chēng)謂。既然懶，那么在創(chuàng)建對(duì)象實(shí)例的時(shí)候就不著急。會(huì)一直等到馬上要使用對(duì)象實(shí)例的時(shí)候才會(huì)創(chuàng)建，懶人嘛，總是推脫不開(kāi)的時(shí)候才會(huì)真正去執(zhí)行工作，因此在裝載對(duì)象的時(shí)候不創(chuàng)建對(duì)象實(shí)例。

privatestaticLazySingletoninstance=null;懶漢式是典型的時(shí)間換空間。就是每次獲取實(shí)例都會(huì)進(jìn)行判斷，看是否需要?jiǎng)?chuàng)建實(shí)例，浪費(fèi)判斷的時(shí)間。當(dāng)然，如果一直沒(méi)有人使用的話，那就不會(huì)創(chuàng)建實(shí)例，則節(jié)約內(nèi)存空間，懶漢式單例模式的實(shí)現(xiàn)登記式單例模式登記式實(shí)際對(duì)一組單例模式進(jìn)行的維護(hù)，主要是在數(shù)量上的擴(kuò)展，通過(guò)map我們把單例存進(jìn)去，這樣在調(diào)用時(shí)，先判斷該單例是否已經(jīng)創(chuàng)建，是的話直接返回，不是的話創(chuàng)建一個(gè)登記到map中，再返回。對(duì)于數(shù)量又分為固定數(shù)量和不固定數(shù)量的。實(shí)現(xiàn)代碼可網(wǎng)上查詢，作為一個(gè)練習(xí)請(qǐng)大家完成。最安全的單例模式優(yōu)化程序如下所示：Python實(shí)現(xiàn)單例模式：第五節(jié) 多例（Multiton）模式多例模式屬于對(duì)象模式多例模式與單例模式一般性結(jié)構(gòu)對(duì)比示意圖：實(shí)用案例：支持多種語(yǔ)言的各類(lèi)程序如網(wǎng)站等多例模式又劃分為有上限多例模式和無(wú)上限多例模式兩種,無(wú)上限多例模式和直接new一個(gè)對(duì)象沒(méi)什么差別,此處不再探究...有上限多例模式:實(shí)際上是單例模式的推廣,如果它的上限是1,那么就成了單例模式了。多例模式特點(diǎn)：

1.多例類(lèi)可以有多個(gè)實(shí)例

2.多例類(lèi)必須自己創(chuàng)建自己的實(shí)例，并管理自己的實(shí)例，和向外界提供自己的實(shí)例一般采用聚集管理所有的實(shí)例多例模式結(jié)構(gòu)

多例模式與單例模式一般性結(jié)構(gòu)對(duì)比：多例模式有如下特點(diǎn)：多例類(lèi)可以有多個(gè)實(shí)例多例類(lèi)必須自己創(chuàng)建自己的實(shí)例，并管理自己的實(shí)例，和向外界提供自己的實(shí)例多例類(lèi)分為有上限多例類(lèi)與無(wú)上限多例類(lèi)。一個(gè)有上限的多例類(lèi)已經(jīng)把實(shí)例的上限當(dāng)作邏輯的一部分，并建造到了多例類(lèi)的內(nèi)部。例子一：兩個(gè)實(shí)例的多例類(lèi)示意性程序代碼例子二：華爾街金融網(wǎng)站支持不同語(yǔ)言這是一個(gè)真實(shí)的面向全球消費(fèi)者的項(xiàng)目的一部分。按照項(xiàng)目計(jì)劃書(shū)，這個(gè)網(wǎng)站系統(tǒng)是要由數(shù)據(jù)庫(kù)驅(qū)動(dòng)的，并且要支持19種不同的語(yǔ)言，而且在將來(lái)支持更多的語(yǔ)言。消費(fèi)者在登錄到系統(tǒng)時(shí)可以選擇自己所需要的語(yǔ)言，系統(tǒng)則根據(jù)用戶的選擇將網(wǎng)站的靜態(tài)文字和動(dòng)態(tài)文字全部轉(zhuǎn)換為用戶所選擇的語(yǔ)言。經(jīng)過(guò)討論，設(shè)計(jì)師們同意對(duì)靜態(tài)文字和動(dòng)態(tài)文字采取不同的解決方案:把所有的網(wǎng)頁(yè)交給翻譯公司對(duì)上面的靜態(tài)文字進(jìn)行翻譯。網(wǎng)頁(yè)上面的動(dòng)態(tài)內(nèi)容需要程序解決。貨幣代碼貨幣名稱(chēng)貨幣尾數(shù)USDUS,Dollars2CNYChina,RenminbiYuan2EURFrance,Euro2JPYJapan，Yen0設(shè)計(jì)師們?cè)谶M(jìn)行了研究后發(fā)現(xiàn)，他們需要解決的動(dòng)態(tài)文字的“翻譯”問(wèn)題，實(shí)際是將數(shù)據(jù)庫(kù)中的一些靜態(tài)或者半靜態(tài)的數(shù)據(jù)進(jìn)行“翻譯”。這里形成一個(gè)典型的數(shù)據(jù)表，如下表所示。程序中貨幣代碼不變，而貨幣名稱(chēng)應(yīng)根據(jù)用戶所選擇的語(yǔ)言不同而不同。比如對(duì)中文讀者就應(yīng)當(dāng)翻譯成為如下表所示的樣子。貨幣代碼貨幣名稱(chēng)貨幣尾數(shù)USD美國(guó)(美利堅(jiān)合眾國(guó))，美元2CNY中國(guó)，人民幣元2EUR法國(guó),歐元2JPY日本，日元0對(duì)日文讀者就應(yīng)當(dāng)翻譯成為如表所示貨幣代碼貨幣名稱(chēng)貨幣尾數(shù)USD米國(guó)(アメリカ合眾國(guó))、ドルで取引を終えた2CNY中國(guó)では、人民元だった2EURフランスで、ユーロ2JPY日本の円0對(duì)法文讀者就應(yīng)當(dāng)翻譯成為如表所示貨幣代碼貨幣名稱(chēng)貨幣尾數(shù)USDAuxétats-Unis,dollars2CNYLaChine,leyuan2EURFrance,euros2JPYAuJapon,yen0這樣的表會(huì)在網(wǎng)頁(yè)上作為下拉菜單出現(xiàn)，用戶看到的是貨幣名稱(chēng)，而系統(tǒng)內(nèi)部使用的是貨幣代碼。系統(tǒng)的內(nèi)核可以是純英文的，在內(nèi)核外部增加-層負(fù)責(zé)語(yǔ)言翻譯工作。所謂內(nèi)核就是系統(tǒng)的模型，而翻譯層便是MVC模式中的視圖層的一部分。對(duì)多語(yǔ)言的支持屬于視圖功能。通過(guò)采用多例模式把對(duì)不同語(yǔ)言的選擇變成不同的參數(shù)并產(chǎn)生不同的對(duì)象再將結(jié)果傳回給讀者?！叭A爾街金融網(wǎng)站”結(jié)構(gòu)圖如圖所示代碼實(shí)現(xiàn)見(jiàn)配套電子版第六節(jié) 建造（Builder）模式建造模式是對(duì)象的創(chuàng)建模式。使用案例：電子郵件子系統(tǒng)電子郵件有多個(gè)組成成分組成，如發(fā)件人地址、收件人地址、主題、內(nèi)容、附件等多個(gè)部分。建造模式解析產(chǎn)品的內(nèi)部表象（internalrepresentation）：一個(gè)產(chǎn)品常有不同的組成成分作為產(chǎn)品的零件，這些零件有可能是對(duì)象，也有可能不是對(duì)象，它們通常又叫做產(chǎn)品的內(nèi)部表象。建造模式可以將一個(gè)產(chǎn)品的內(nèi)部表象與產(chǎn)品的生產(chǎn)過(guò)程分割開(kāi)來(lái)，從而可以使一個(gè)建造過(guò)程生成具有不同的內(nèi)部表象的產(chǎn)品對(duì)象。不同的產(chǎn)品可以有不同的內(nèi)部表象，也就是不同的零件。建造模式將產(chǎn)品的內(nèi)部表象和產(chǎn)品的生成過(guò)程分開(kāi)來(lái)，從而使一個(gè)建造過(guò)程生成具有不同的內(nèi)部表象的產(chǎn)品對(duì)象。建造模式使得產(chǎn)品內(nèi)部表象可以獨(dú)立的變化，客戶不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)。建造模式可以強(qiáng)制實(shí)行一種分步驟進(jìn)行的建造過(guò)程。6.1 建造模式的適用場(chǎng)景有些情況下，一個(gè)對(duì)象會(huì)有一些重要的性質(zhì)，在它們沒(méi)有恰當(dāng)?shù)闹抵?，?duì)象不能作為一個(gè)完整的產(chǎn)品使用。比如，一個(gè)電子郵件有發(fā)件人地址、收件人地址、主題、內(nèi)容、附錄等部分，而在最起碼的收件人地址得到賦值之前，這個(gè)電子郵件不能發(fā)送。6.2 在什么情況下使用建造模式需要生成的產(chǎn)品對(duì)象有復(fù)雜的內(nèi)部結(jié)構(gòu)，每一個(gè)內(nèi)部成分本身可以是對(duì)象，也可以僅僅是一個(gè)對(duì)象（即產(chǎn)品對(duì)象）的一個(gè)組成部分。需要生成的產(chǎn)品對(duì)象的屬性相互依賴(lài)。建造模式可以強(qiáng)制實(shí)行一種分步驟進(jìn)行的建造過(guò)程，因此，如果產(chǎn)品對(duì)象的一個(gè)屬性必須在另一個(gè)屬性被賦值之后才可以被賦值，使用建造模式是一個(gè)很好的設(shè)計(jì)思想。在對(duì)象創(chuàng)建過(guò)程中會(huì)使用到系統(tǒng)中的其他一些對(duì)象，這些對(duì)象在產(chǎn)品對(duì)象的創(chuàng)建過(guò)程中不易得到。6.3 建造模式的特點(diǎn)使用建造模式可以使客戶端不需要知道所生成的產(chǎn)品有哪些零件，每個(gè)產(chǎn)品的對(duì)應(yīng)零件彼此有何不同，是怎么建造出來(lái)的，以及怎么組成產(chǎn)品。建造模式利用一個(gè)導(dǎo)演者對(duì)象和具體建造者對(duì)象一個(gè)個(gè)地建造出所有的零件，從而建造出完整的產(chǎn)品對(duì)象。建造者模式將產(chǎn)品結(jié)構(gòu)和產(chǎn)品零件的建造過(guò)程對(duì)客戶端隱藏起來(lái)，把對(duì)建造過(guò)程進(jìn)行指揮的責(zé)任和具體建造者零件的責(zé)任分割開(kāi)來(lái)，達(dá)到責(zé)任劃分和封裝的目的。6.4 建造模式的結(jié)構(gòu)不管如何變化，建造模式都存在這么兩個(gè)部分部件構(gòu)造和產(chǎn)品裝配，整體構(gòu)建的算法。認(rèn)識(shí)這點(diǎn)是很重要的，因?yàn)樵诮ㄔ炷Ｊ街?，?qiáng)調(diào)的是固定整體構(gòu)建的算法，而靈活擴(kuò)展和切換部件的具體構(gòu)造和產(chǎn)品裝配的方式。建造模式的示意性結(jié)構(gòu)圖在這個(gè)示意性的系統(tǒng)里，最終產(chǎn)品Product只有兩個(gè)零件，即part1和part2。相應(yīng)的建造方法也有兩個(gè)：buildPart1()和buildPart2()同時(shí)可以看出本模式涉及到四個(gè)角色，它們分別是：抽象建造者角色：給出一個(gè)抽象接口，以規(guī)范產(chǎn)品對(duì)象的各個(gè)組成成分的建造。具體建造者角色：在應(yīng)用程序調(diào)用下創(chuàng)建產(chǎn)品的實(shí)例。導(dǎo)演者角色：調(diào)用具體建造者角色以創(chuàng)建產(chǎn)品對(duì)象。產(chǎn)品角色：建造的各種復(fù)雜對(duì)象，這些產(chǎn)品類(lèi)并不一定有共同的接口，而完全可以是不相關(guān)聯(lián)的。一般來(lái)說(shuō)，每有一個(gè)產(chǎn)品類(lèi)，就有一個(gè)相應(yīng)的具體建造者類(lèi)。這些產(chǎn)品應(yīng)當(dāng)有同樣數(shù)目的零件，而每有一個(gè)零件就相應(yīng)地在所有的建造者角色里有一個(gè)建造方法。建造模式的實(shí)現(xiàn)練習(xí)：構(gòu)建電子郵件信箱發(fā)送郵件模塊系統(tǒng)需求分析：假設(shè)有一個(gè)系統(tǒng)需要定期向用戶電子郵件信箱發(fā)送電子雜志。用戶可以通過(guò)網(wǎng)頁(yè)訂閱電子雜志，也可以通過(guò)網(wǎng)頁(yè)結(jié)束訂閱。當(dāng)客戶開(kāi)始訂閱時(shí)，系統(tǒng)發(fā)送一個(gè)電子郵件表示歡迎，當(dāng)客戶結(jié)束訂閱時(shí)，系統(tǒng)發(fā)送一個(gè)電子郵件表示歡送。本例就是這個(gè)系統(tǒng)負(fù)責(zé)發(fā)送“歡迎”和“歡送”郵件的模塊。系統(tǒng)設(shè)計(jì)在本例中，產(chǎn)品類(lèi)就是發(fā)給某個(gè)客戶的“歡迎”和“歡送”郵件，如圖所示。雖然在這個(gè)例子里面各個(gè)產(chǎn)品類(lèi)均有一個(gè)共同的接口，但這僅僅是本例子特有的，并不代表建造模式的特點(diǎn)。建造模式可以應(yīng)用到具有完全不同接口的產(chǎn)品類(lèi)上。大多數(shù)情況下是不知道最終構(gòu)建出來(lái)的產(chǎn)品是什么樣的，所以在標(biāo)準(zhǔn)的建造模式里面，一般是不需要對(duì)產(chǎn)品定義抽象接口的，因?yàn)樽罱K構(gòu)造的產(chǎn)品千差萬(wàn)別，給這些產(chǎn)品定義公共接口幾乎是沒(méi)有意義的。系統(tǒng)采用建造模式設(shè)計(jì)的結(jié)構(gòu)圖這個(gè)系統(tǒng)含有客戶端（Client）、導(dǎo)演者（Director）、抽象建造者（Builder）、具體建造者（WelcomeBuilder和GoodbyeBuilder）、產(chǎn)品（WelcomeMessage和GoodbyeMessage）等角色。第七節(jié) 原型（Prototype）模式原型模式屬于對(duì)象的創(chuàng)建模式。通過(guò)給出一個(gè)原型對(duì)象來(lái)指明所有創(chuàng)建的對(duì)象的類(lèi)型，然后用復(fù)制這個(gè)原型對(duì)象的辦法創(chuàng)建出更多同類(lèi)型的對(duì)象。這就是原型模式的用意。實(shí)用案例：需要快速創(chuàng)建同類(lèi)對(duì)象的需求使用原型模式的好處使用原型模式創(chuàng)建對(duì)象比直接new一個(gè)對(duì)象在性能上要好的多，因?yàn)镺bject類(lèi)的clone方法是一個(gè)本地方法，它直接操作內(nèi)存中的二進(jìn)制流，特別是復(fù)制大對(duì)象時(shí)，性能的差別非常明顯。簡(jiǎn)化對(duì)象的創(chuàng)建，使得創(chuàng)建對(duì)象就像我們?cè)诰庉嬑臋n時(shí)的復(fù)制粘貼一樣簡(jiǎn)單。因?yàn)橐陨蟽?yōu)點(diǎn)，在需要重復(fù)地創(chuàng)建相似對(duì)象時(shí)可以考慮使用原型模式。例子：孫悟空身外身法術(shù)從孫大圣的手段談起孫悟空在與黃風(fēng)怪的戰(zhàn)斗中，“使一個(gè)身外身的手段：把毫毛揪下一把，用口嚼得粉碎，望上一噴，叫聲‘變’，變有百十個(gè)行者，都是一樣打扮，各執(zhí)一根鐵棒，把那怪圍在空中?！边@個(gè)例子中，孫悟空可以根據(jù)自己的形象，復(fù)制出很多“身外之身”來(lái)。例子總結(jié)老孫的這種身外身的手段在面向?qū)ο蟮脑O(shè)計(jì)領(lǐng)域里叫做原型(Prototype)模式。原型模式通過(guò)給出一個(gè)原型對(duì)象來(lái)指明所要?jiǎng)?chuàng)建的對(duì)象的類(lèi)型，然后用復(fù)制這個(gè)原型對(duì)象的方法創(chuàng)建出更多同類(lèi)型的對(duì)象。原始模型模式允許動(dòng)態(tài)的增加或減少產(chǎn)品類(lèi)，產(chǎn)品類(lèi)不需要非得有任何事先確定的等級(jí)結(jié)構(gòu)，原始模型模式適用于任何的等級(jí)結(jié)構(gòu)。原始模型模式缺點(diǎn)是每一個(gè)類(lèi)都必須配備一個(gè)克隆方法。原型模式的結(jié)構(gòu)原型模式要求對(duì)象實(shí)現(xiàn)一個(gè)可以“克隆”自身的接口，這樣就可以通過(guò)復(fù)制一個(gè)實(shí)例對(duì)象本身來(lái)創(chuàng)建一個(gè)新的實(shí)例。這樣一來(lái)，通過(guò)原型實(shí)例創(chuàng)建新的對(duì)象，就不再需要關(guān)心這個(gè)實(shí)例本身的類(lèi)型，只要實(shí)現(xiàn)了克隆自身的方法，就可以通過(guò)這個(gè)方法來(lái)獲取新的對(duì)象，而無(wú)須再去通過(guò)new來(lái)創(chuàng)建。原型模式有兩種表現(xiàn)形式：（1）簡(jiǎn)單形式（2）登記形式這兩種表現(xiàn)形式僅僅是原型模式的不同實(shí)現(xiàn)。7.1

簡(jiǎn)單形式的原型模式簡(jiǎn)單形式的原型