軟件設(shè)計(jì)模式JAVA習(xí)題答案

1、-. z.軟件設(shè)計(jì)模式Java版習(xí)題第1章軟件設(shè)計(jì)模式根底1.1 軟件設(shè)計(jì)模式概述1.2 UML中的類圖1.3 面向?qū)ο蟮脑O(shè)計(jì)原則名詞解釋一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉，即在不修改源代碼的根底上擴(kuò)展一個(gè)系統(tǒng)的行為。一個(gè)對(duì)象應(yīng)該只包含單一的職責(zé)，并且該職責(zé)被完整地封裝在一個(gè)類中。在軟件中如果能夠使用基類對(duì)象，則一定能夠使用其子類對(duì)象。是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過(guò)分類編目的、代碼設(shè)計(jì)經(jīng)歷的總結(jié)，使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。單項(xiàng)選擇擇題( A ) 2. A 3. ( A ) 4. ( D ) 5. ( D ) 6( A ) 7. ( D )

2、8. D 9. D 10. E 11.( C ) 12 C 13. ( A ) 多項(xiàng)選擇擇題1( A、B、C、D ) 2. ( A、B ) 3( A、D ) 4( A、B、C、D )填空題1依賴倒轉(zhuǎn)、迪米特法則、單一職責(zé)2模式名字、目的、問(wèn)題、解決方案、效果、實(shí)例代碼3超類、子類4開(kāi)閉5用戶6依賴倒轉(zhuǎn)7組合/聚合8構(gòu)造型、行為型依賴倒轉(zhuǎn)開(kāi)閉需求收集是否正確、體系構(gòu)造的構(gòu)建是否合理、測(cè)試是否完全12人與人之間的交流13接口14名稱、目的、解決方案15對(duì)象組合、類繼承16對(duì)象組合17對(duì)象組合、類繼承18抽象類的指針五、簡(jiǎn)答題1.答：設(shè)計(jì)模式按類型分為以下三類：創(chuàng)立型設(shè)計(jì)模式：以靈活的方式創(chuàng)立對(duì)象集

3、合，用于管理對(duì)象的創(chuàng)立。構(gòu)造型設(shè)計(jì)模式：將己有的代碼集成到新的面向?qū)ο笤O(shè)計(jì)中，用于處理類或?qū)ο蟮慕M合。行為型設(shè)計(jì)模式：用于描述對(duì)類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)。2.答：設(shè)計(jì)模式的主要優(yōu)點(diǎn)如下：設(shè)計(jì)模式融合了眾多專家的經(jīng)歷，并以一種標(biāo)準(zhǔn)的形式供廣闊開(kāi)發(fā)人員所用，它提供了一套通用的設(shè)計(jì)詞匯和一種通用的語(yǔ)言以方便開(kāi)發(fā)人員之間溝通和交流，使得設(shè)計(jì)方案更加通俗易懂。設(shè)計(jì)模式使人們可以更加簡(jiǎn)單方便地復(fù)用成功的設(shè)計(jì)和體系構(gòu)造，將已證實(shí)的技術(shù)表述成設(shè)計(jì)模式也會(huì)使新系統(tǒng)開(kāi)發(fā)者更加容易理解其設(shè)計(jì)思路。設(shè)計(jì)模式使得重用成功的設(shè)計(jì)更加容易，并防止那些導(dǎo)致不可重用的設(shè)計(jì)方案。設(shè)計(jì)模式使得設(shè)計(jì)方案更加靈活，且易于修改。設(shè)

4、計(jì)模式的使用將提高軟件系統(tǒng)的開(kāi)發(fā)效率和軟件質(zhì)量，且在一定程度上節(jié)約設(shè)計(jì)本錢。設(shè)計(jì)模式有助于初學(xué)者更深入地理解面向?qū)ο笏枷?，一方面可以幫助初學(xué)者更加方便地閱讀和學(xué)習(xí)現(xiàn)有類庫(kù)與其他系統(tǒng)中的源代碼，另一方面還可以提高軟件的設(shè)計(jì)水平和代碼質(zhì)量。答：設(shè)計(jì)模式一般有如下幾個(gè)根本要素：模式名稱、問(wèn)題、目的、解決方案、效果、實(shí)例代碼和相關(guān)設(shè)計(jì)模式，其中的關(guān)鍵元素包括模式名稱、問(wèn)題、解決方案和效果。答：正確使用設(shè)計(jì)模式具有以下優(yōu)點(diǎn)：可以提高程序員的思維能力、編程能力和設(shè)計(jì)能力。使程序設(shè)計(jì)更加標(biāo)準(zhǔn)化、代碼編制更加工程化，使軟件開(kāi)發(fā)效率大大提高，從而縮短軟件的開(kāi)發(fā)周期。使設(shè)計(jì)的代碼可重用性高、可讀性強(qiáng)、可靠性高、靈

5、活性好、可維護(hù)性強(qiáng)。答：根據(jù)類與類之間的耦合度從弱到強(qiáng)排列，UML中的類圖有以下幾種關(guān)系：依賴關(guān)系、關(guān)聯(lián)關(guān)系、聚合關(guān)系、組合關(guān)系、泛化關(guān)系和實(shí)現(xiàn)關(guān)系。其中泛化和實(shí)現(xiàn)的耦合度相等，它們是最強(qiáng)的。答：1開(kāi)閉原則OCP：它要求軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉；里氏替換原則LSP：它要求繼承必須確保超類所擁有的性質(zhì)在子類中仍然成立；依賴倒置原則DIP：它要求軟件設(shè)計(jì)要面向接口編程，不要面向?qū)崿F(xiàn)編程；單一職責(zé)原則SRP：它要求對(duì)象不應(yīng)該承當(dāng)太多職責(zé)，一個(gè)類應(yīng)該有且僅有一個(gè)引起它變化的原因；接口隔離原則ISP：它要求程序員盡量將臃腫龐大的接口拆分成更小的和更具體的接口，讓接口中只包含客戶感興趣的方法；迪

6、米特法則LoD：它要求如果兩個(gè)軟件實(shí)體無(wú)須直接通信，就不應(yīng)當(dāng)直接相互調(diào)用，而通過(guò)第三方轉(zhuǎn)發(fā)該調(diào)用；合成復(fù)用原則CRP：它要求在軟件復(fù)用時(shí)，要盡量先使用組合或者聚合等關(guān)聯(lián)關(guān)系來(lái)實(shí)現(xiàn)，其次才考慮使用繼承關(guān)系來(lái)實(shí)現(xiàn)。第2章創(chuàng)立型模式上2.2 單例模式2.3 原型模式單項(xiàng)選擇擇題1. A 2. B 3. ( A ) 4. ( D ) 5. ( C ) 6( B ) 7. ( B ) 多項(xiàng)選擇擇題1. C 2. ( A，B ) 3. A、B 4. ( A、B、C ) 5. A、C 6( A、B、C、D ) 7( A,B,C,D ) 填空題1對(duì)象的創(chuàng)立、使用別離、耦合度2創(chuàng)立型3創(chuàng)立性4懶漢式單例、餓漢式

7、單例5. 抽象原型類、具體原型類程序分析題解：此題使用了單例模式，參考類圖如下所示：簡(jiǎn)答題1. 答：創(chuàng)立型模式分為以下幾種：?jiǎn)卫齋ingleton模式：*個(gè)類只能生成一個(gè)實(shí)例，該類提供了一個(gè)全局訪問(wèn)點(diǎn)供外部獲取該實(shí)例，其拓展是有限多例模式。原型Prototype模式：將一個(gè)對(duì)象作為原型，通過(guò)對(duì)其進(jìn)展復(fù)制而克隆出多個(gè)和原型類似的新實(shí)例。工廠方法Factory Method模式：定義一個(gè)用于創(chuàng)立產(chǎn)品的接口，由子類決定生產(chǎn)什么產(chǎn)品。抽象工廠Abstract Factory模式：提供一個(gè)創(chuàng)立產(chǎn)品族的接口，其每個(gè)子類可以生產(chǎn)一系列相關(guān)的產(chǎn)品。建造者Builder模式：將一個(gè)復(fù)雜對(duì)象分解成多個(gè)相對(duì)簡(jiǎn)單的局

8、部，然后根據(jù)不同需要分別創(chuàng)立它們，最后構(gòu)建成該復(fù)雜對(duì)象。2答：?jiǎn)卫Ｊ街攸c(diǎn)在于在整個(gè)系統(tǒng)上共享一些創(chuàng)立時(shí)較耗資源的對(duì)象。整個(gè)應(yīng)用中只維護(hù)一個(gè)特定類實(shí)例，它被所有組件共同使用。是單例模式的經(jīng)典例子。從Java 5開(kāi)場(chǎng)你可以使用枚舉enum來(lái)實(shí)現(xiàn)線程平安的單例。答：?jiǎn)卫齋ingleton模式的定義：指一個(gè)類只有一個(gè)實(shí)例，且該類能自行創(chuàng)立這個(gè)實(shí)例的一種模式。特點(diǎn)：1單例類只有一個(gè)實(shí)例對(duì)象；2該單例對(duì)象必須由單例類自行創(chuàng)立；3單例類對(duì)外提供一個(gè)訪問(wèn)該單例的全局訪問(wèn)點(diǎn)。應(yīng)用場(chǎng)景：1在*類只要求生成一個(gè)對(duì)象的時(shí)候；2當(dāng)對(duì)象需要被共享的場(chǎng)合；3當(dāng)*類需要頻繁實(shí)例化，而創(chuàng)立的對(duì)象又頻繁被銷毀的時(shí)候。答：原型模

9、式通常適用以下場(chǎng)景：1對(duì)象之間一樣或相似，即只是個(gè)別的幾個(gè)屬性不同的時(shí)候；2對(duì)象的創(chuàng)立過(guò)程比擬麻煩，但克隆比擬簡(jiǎn)單時(shí)候。原型模式可擴(kuò)展為：帶原型管理器的原型模式，它在原型模式的根底上增加了一個(gè)原型管理器PrototypeManager類。第3章創(chuàng)立型模式下工廠方法模式抽象工廠模式建造者模式單項(xiàng)選擇擇題( B ) 2. ( A ) 3. ( C ) 4. C 5. ( D ) 6. ( C ) 7. ( B ) 8. ( A ) 9. A 10. A 多項(xiàng)選擇擇題1( A、B、C、D ) 2( A、B、C、D ) 3. A、C 填空題1工廠方法、抽象工廠簡(jiǎn)單工廠抽象工廠(Abstract Fac

10、tory)、具體工廠(Concrete Factory)、抽象產(chǎn)品(Product) 工廠方法、多個(gè)等級(jí)的產(chǎn)品抽象建造者Builder、具體建造者ConcreteBuilder、指揮者Director五、簡(jiǎn)答題1答：工廠模式的最大好處是增加了創(chuàng)立對(duì)象時(shí)的封裝層次。如果你使用工廠來(lái)創(chuàng)立對(duì)象，之后你可以使用更高級(jí)和更高性能的實(shí)現(xiàn)來(lái)替換原始的產(chǎn)品實(shí)現(xiàn)或類，這不需要在調(diào)用層做任何修改。應(yīng)用場(chǎng)合是常常有新的對(duì)象類型要被添加進(jìn)來(lái)，但你所關(guān)心的僅僅是方法的接口,不關(guān)心其實(shí)現(xiàn)細(xì)節(jié)，本書(shū)中已經(jīng)詳細(xì)地介紹了其好處和應(yīng)用環(huán)境。2.答：工廠方法模式的主要優(yōu)點(diǎn)有：1用戶只需要知道具體工廠的名稱就可得到所要的產(chǎn)品，無(wú)須知

11、道產(chǎn)品的具體創(chuàng)立過(guò)程；2在系統(tǒng)增加新的產(chǎn)品時(shí)只需要添加具體產(chǎn)品類和對(duì)應(yīng)的具體工廠類，無(wú)需對(duì)原工廠進(jìn)展任何修改，滿足開(kāi)閉原則。其缺點(diǎn)是：每增加一個(gè)產(chǎn)品就要增加一個(gè)具體產(chǎn)品類和一個(gè)對(duì)應(yīng)的具體工廠類，這增加了系統(tǒng)的復(fù)雜度。3.答：工廠方法模式中考慮的是一類產(chǎn)品的生廠，如：電視機(jī)工廠；而抽象工廠模式考慮多類產(chǎn)品的生產(chǎn)，如：電器工廠。工廠方法模式通常適用以下場(chǎng)景：1客戶只知道創(chuàng)立產(chǎn)品的工廠名,而不知道具體的產(chǎn)品名。如：TCL 電視工廠、海信電視工廠等；2創(chuàng)立對(duì)象的任務(wù)由多個(gè)具體子工廠中的*一個(gè)完成，而抽象工廠只提供創(chuàng)立產(chǎn)品的接口。3客戶不關(guān)心創(chuàng)立產(chǎn)品的細(xì)節(jié)，只關(guān)心產(chǎn)品的品牌。抽象工廠模式通常適用以下場(chǎng)景

12、： 1當(dāng)需要?jiǎng)?chuàng)立的對(duì)象是一系列相互關(guān)聯(lián)或相互依賴的產(chǎn)品族時(shí)，如：電器工廠中的電視機(jī)、洗衣機(jī)、空調(diào)等；2系統(tǒng)中有多個(gè)產(chǎn)品族，但每次只使用其中的*一族產(chǎn)品。如：有的粉絲只喜歡穿寧牌的衣、褲和鞋；3系統(tǒng)中提供了產(chǎn)品的類庫(kù)，且所有產(chǎn)品的接口一樣，客戶端不依賴產(chǎn)品實(shí)例的創(chuàng)立細(xì)節(jié)和部構(gòu)造。4.答：產(chǎn)品的種類稱為產(chǎn)品等級(jí)，而一個(gè)具體工廠所生產(chǎn)的位于不同等級(jí)的一組產(chǎn)品稱為一個(gè)產(chǎn)品族。5.答：建造者模式的定義: 指將一個(gè)復(fù)雜對(duì)象的構(gòu)造與它的表示別離，使同樣的構(gòu)建過(guò)程可以創(chuàng)立不同的表示，這樣的設(shè)計(jì)模式被稱為建造者模式。該模式的主要優(yōu)點(diǎn)是： 1各個(gè)具體的建造者相互獨(dú)立的，有利于系統(tǒng)的擴(kuò)展；2客戶端不必知道產(chǎn)品部組成

13、的細(xì)節(jié)，便于控制細(xì)節(jié)風(fēng)險(xiǎn)。其缺點(diǎn)是：1產(chǎn)品的組成局部必須一樣，這限制了其使用圍；2如果產(chǎn)品的部變化復(fù)雜，該模式會(huì)增加很多的建造者類。建造者模式通常在以下場(chǎng)合使用： 1創(chuàng)立的對(duì)象較復(fù)雜，由多個(gè)部件構(gòu)成，各部件面臨著復(fù)雜的變化，但構(gòu)件間的建造順序是穩(wěn)定的；2創(chuàng)立復(fù)雜對(duì)象的算法獨(dú)立于該對(duì)象的組成局部以及它們的裝配方式，即產(chǎn)品的構(gòu)建過(guò)程和最終的表示是獨(dú)立的。六、編程題說(shuō)明：1-5編程題可參考本章節(jié)的實(shí)例自己實(shí)現(xiàn)。第4章構(gòu)造型模式上4.2 代理模式4.3 適配器模式4.4 橋接模式單項(xiàng)選擇擇題( A ) 2. A 3. ( D ) 4. ( B ) 5. ( A ) 6. ( C ) 7. ( D )

14、多項(xiàng)選擇擇題1. A、D 2. ( A、B、D ) 3. A、C、D 4. ( A、B、C ) 填空題適配器Adapter模式、橋接(Bridge)模式、裝飾(Decorator)模式、外觀(Facade) 模式、享元(Flyweight)模式真實(shí)主題RealSubject類、代理Pro*y類動(dòng)態(tài)代理模式4繼承、組合/聚合5. 適配者Adaptee類、適配器Adapter類6橋接7. 適配器程序分析題解：1此題使用了代理器模式； 2其參考構(gòu)造圖如下所示：五、簡(jiǎn)答題答：代理Pro*y模式：為*對(duì)象提供一種代理以控制對(duì)該對(duì)象的訪問(wèn)。即客戶端通過(guò)代理間接地訪問(wèn)該對(duì)象，從而限制、增強(qiáng)或修改該對(duì)象的一些

15、特性。代理模式有以下的應(yīng)用場(chǎng)景：1為了隱藏目標(biāo)對(duì)象存在于不同地址空間的事實(shí)，方便客戶端訪問(wèn)時(shí)；2要?jiǎng)?chuàng)立的目標(biāo)對(duì)象開(kāi)銷很大時(shí)；3控制不同種類客戶對(duì)真實(shí)對(duì)象的訪問(wèn)權(quán)限時(shí)；4當(dāng)調(diào)用目標(biāo)對(duì)象需要附加一些額外的處理功能時(shí)；5為了提高系統(tǒng)的性能，需延遲對(duì)目標(biāo)的加載時(shí)。答：代理模式的主要優(yōu)點(diǎn)有：1代理模式在客戶端與目標(biāo)對(duì)象之間起到一個(gè)中介作用和保護(hù)目標(biāo)對(duì)象的作用；2代理對(duì)象可以擴(kuò)展目標(biāo)對(duì)象的功能；3代理模式能將客戶端與目標(biāo)對(duì)象別離，在一定程度上降低了系統(tǒng)的耦合度。其主要缺點(diǎn)是：1在客戶端和目標(biāo)對(duì)象增加一個(gè)代理對(duì)象，會(huì)造成請(qǐng)求處理速度變慢； 2增加了系統(tǒng)的復(fù)雜度。答：遠(yuǎn)程代理：這種方式通常是為了隱藏目標(biāo)對(duì)象存

16、在于不同地址空間的事實(shí)，方便客戶端訪問(wèn)。例如用戶申請(qǐng)*些網(wǎng)盤(pán)空間時(shí)，會(huì)在用戶的文件系統(tǒng)中建立一個(gè)虛擬的硬盤(pán)，用戶訪問(wèn)它實(shí)際訪問(wèn)的是網(wǎng)盤(pán)空間。虛擬代理：這種方式通常用于要?jiǎng)?chuàng)立的目標(biāo)對(duì)象開(kāi)銷很大時(shí)。比方下載一幅很大的圖像需要很長(zhǎng)時(shí)間，因*種計(jì)算比擬復(fù)雜而短時(shí)間無(wú)法完成，這時(shí)可以先用小比例的虛擬代理替換真實(shí)的對(duì)象，消除用戶對(duì)效勞器慢的感覺(jué)。平安代理：這種方式通常用于控制不同種類客戶對(duì)真實(shí)對(duì)象的訪問(wèn)權(quán)限。答：適配器模式Adapter的定義如下: 將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口，使得原本由于接口不兼容而不能一起工作的那些類能一起工作。適配器模式分為類構(gòu)造型模式和對(duì)象構(gòu)造型模式2種，前者類之間

17、的耦合度比后者高，且要求程序員了解現(xiàn)有組件庫(kù)中的相關(guān)組件的部構(gòu)造，所以應(yīng)用相對(duì)較少些。Java例子可參考本章節(jié)相關(guān)實(shí)例設(shè)計(jì)。答：適配器模式通常適用以下場(chǎng)景： 1以前開(kāi)發(fā)的系統(tǒng)存在滿足新系統(tǒng)功能需求的類，但其接口同新系統(tǒng)的接口不一致；2使用第三方提供的組件，但組件接口定義和自己要求的接口定義不同。應(yīng)用實(shí)例可參考本章節(jié)相關(guān)實(shí)例設(shè)計(jì)。答：橋接模式的定義如下: 將抽象與實(shí)現(xiàn)別離，使他們可以獨(dú)立的變化。它是用組合關(guān)系代替繼承關(guān)系來(lái)實(shí)現(xiàn)，從而降低了抽象和實(shí)現(xiàn)這2個(gè)可變維度的耦合度。其優(yōu)點(diǎn)是： 1由于抽象與實(shí)現(xiàn)別離，所以擴(kuò)展能力強(qiáng)；2其實(shí)現(xiàn)細(xì)節(jié)對(duì)客戶透明。缺點(diǎn)是：由于聚合關(guān)系建立在抽象層，要求開(kāi)發(fā)者針對(duì)抽象

18、化進(jìn)展設(shè)計(jì)與編程，這增加了系統(tǒng)的理解與設(shè)計(jì)難度。六、綜合題1解：此題可使用適配器模式和抽象工廠模式，參考類圖如下所示：其中：1PlayerFactory為抽象工廠，MediaPlayerFactory和RealPlayerFactory是具體工廠；MainWindow主窗口和PlayerList播放列表是兩個(gè)抽象產(chǎn)品；MediaPlayerWindow和RealPlayerWindow是兩個(gè)具體產(chǎn)品，是對(duì)MainWindow的實(shí)現(xiàn)；MediaPlayerList和RealPlayerList是兩個(gè)具體產(chǎn)品，是對(duì)PlayerList的實(shí)現(xiàn)；MediaPlayerWindow和MediaPlaye

19、rList由MediaPlayerFactory生產(chǎn)；RealPlayerWindow和RealPlayerList由RealPlayerFactory生產(chǎn)；MediaPlayerAPI是已有的API，充當(dāng)適配者，供MediaPlayerWindow適配器和 MediaPlayerList適配器調(diào)用。RealPlayerAPI也是已有的API，充當(dāng)適配者，供RealPlayerWindow適配器和 RealPlayerList適配器調(diào)用。第5章構(gòu)造型模式下5.1 裝飾模式5.2 外觀模式5.3 享元模式5.4 組合模式單項(xiàng)選擇擇題1. ( D ) 2. ( D ) 3. ( B ) 4. (

20、C ) 5. B 6( C ) 7. ( D ) 8. ( A ) 9. ( B ) 10.( C ) 多項(xiàng)選擇擇題1( A,B,C,D ) 2. B,C 3. A、B 4( A、B、C ) 5. ( A、B、C、D ) 6( A,B ) 7. ( C,D ) 填空題1.抽象構(gòu)件ponent、具體構(gòu)件Concrete ponent、抽象裝飾Decorator 2.迪米特 3.部狀態(tài)、外部狀態(tài)4.單純、復(fù)合5.構(gòu)造型、創(chuàng)立型6.透明式、平安式四、程序分析題解：此題使用了享元模式，參考類圖如下所示：解：1此題使用了享元模式。 2其參考程序代碼如下所示： import java.util.*; pu

21、blic class WareFactory private ArrayList Wares = new ArrayList(); private int totalNum=0; public WareFactory() KitchenWare nd1=new bowl(飯碗); Wares.add(nd1); KitchenWare nd2=new cup(杯子); Wares.add(nd2); public KitchenWare getKitchenWare(String type) if(type.equalsIgnoreCase(飯碗) totalNum+; return (Kit

22、chenWare)Wares.get(0); else if(type.equalsIgnoreCase(杯子) totalNum+; return (KitchenWare)Wares.get(1); else return null; public int getTotalWare() return Wares.size(); public int gettotalNum() return totalNum; public interface KitchenWare public String getType(); public void use(); public class bowl

23、implements KitchenWare private String type; public bowl(String type) this.type=type; public String getType() return this.type; public void use() System.out.println(使用的廚具是： + this.type); public class cup implements KitchenWare private String type; public cup(String type) this.type=type; public String

24、 getType() return this.type; public void use() System.out.println(使用的廚具是： +this.type); public class Client2010 public static void main(String args) KitchenWare kw1,kw2,kw3,kw4; WareFactory df=new WareFactory(); kw1=df.getKitchenWare(飯碗); kw1.use(); kw2=df.getKitchenWare(飯碗); kw2.use(); kw3=df.getKit

25、chenWare(杯子); kw3.use(); kw4=df.getKitchenWare(杯子); kw4.use(); System.out.println(廚具種類: + df.getTotalWare(); System.out.println(生成的廚具數(shù): + df.gettotalNum(); 五、簡(jiǎn)答題1答：裝飾模式增加強(qiáng)了單個(gè)對(duì)象的能力。Java IO 到處都使用了裝飾模式，經(jīng)典的例子就是Buffered系列類如BufferedReader和BufferedWriter，它們?cè)鰪?qiáng)了Reader和Writer對(duì)象，以實(shí)現(xiàn)提升性能的 Buffer 層次的讀取和寫(xiě)入。答：裝飾模式

26、是一種用于替代繼承的技術(shù)，它使用對(duì)象之間的關(guān)聯(lián)關(guān)系來(lái)取代類之間的繼承關(guān)系。當(dāng)不能采用繼承的方式對(duì)系統(tǒng)進(jìn)展擴(kuò)展或者采用繼承不利于系統(tǒng)擴(kuò)展和維護(hù)時(shí)可以使用裝飾模式。在裝飾模式中引入了裝飾類，在裝飾類中既可以調(diào)用待裝飾的原有類的方法，還可以增加新的方法，以擴(kuò)大原有類的功能。這些都不用改變?cè)袑?duì)象，滿足開(kāi)閉原則。答：外觀模式的定義：是一種通過(guò)為多個(gè)復(fù)雜的子系統(tǒng)提供一個(gè)一致的接口，而使這些子系統(tǒng)更加容易被訪問(wèn)的模式。其主要優(yōu)點(diǎn)有：1降低了子系統(tǒng)與客戶端之間的耦合度，使得子系統(tǒng)的變化不會(huì)影響到調(diào)用它的客戶類；2對(duì)客戶屏蔽了子系統(tǒng)組件，減少了客戶處理的對(duì)象數(shù)目，并使得子系統(tǒng)使用起來(lái)更加容易；3降低了大型軟件

27、系統(tǒng)中的編譯依賴性，簡(jiǎn)化了系統(tǒng)在不同平臺(tái)之間的移植過(guò)程，因?yàn)榫幾g一個(gè)子系統(tǒng)不會(huì)影響其他的子系統(tǒng)，也不會(huì)影響到外觀對(duì)象。其主要缺點(diǎn)是：1不能很好地限制客戶使用子系統(tǒng)類；2增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了開(kāi)閉原則。其應(yīng)用場(chǎng)景有：1對(duì)分層構(gòu)造系統(tǒng)構(gòu)建時(shí)，使用外觀模式定義子系統(tǒng)中每層的入口點(diǎn)可以簡(jiǎn)化子系統(tǒng)之間的依賴關(guān)系；2對(duì)于一個(gè)復(fù)雜系統(tǒng)，其子系統(tǒng)很多，外觀模式可以為系統(tǒng)設(shè)計(jì)一個(gè)簡(jiǎn)單的接口供外界訪問(wèn)；3當(dāng)客戶端與多個(gè)子系統(tǒng)之間存在很大的聯(lián)系時(shí)，引入外觀模式可將它們別離，從而提高子系統(tǒng)的獨(dú)立性和可移植性。答：享元工廠角色負(fù)責(zé)創(chuàng)立和管理享元角色。當(dāng)客戶對(duì)象請(qǐng)求一個(gè)享元對(duì)象時(shí)，享元工

28、廠檢查系統(tǒng)中是否存在符合要求的享元對(duì)象，如果存在則提供應(yīng)客戶；如果不存在的話，則創(chuàng)立一個(gè)新的享元對(duì)象，它是工廠模式在享元模式中的應(yīng)用。答：組合模式包含抽象構(gòu)件ponent角色、樹(shù)葉構(gòu)件Leaf角色、樹(shù)枝構(gòu)件posite角色。它分為透明式的組合模式和平安式的組合模式2種。平安組合模式的類圖如下：第6章行為型模式上6.2 模板方法模式6.3 策略模式6.4 命令模式單項(xiàng)選擇擇題( A ) 2. ( D ) 3. ( C ) 4. ( B ) 5. ( A ) 6. B 7. ( D ) 8. ( A ) 9. ( B ) 多項(xiàng)選擇擇題1. B,C,D 2. ( A,B,D ) 3. ( A,B,C

29、 ) 4. A，B，C，D 填空題行為型模式模板方法抽象方法、具體方法、鉤子方法策略簡(jiǎn)單工廠命令簡(jiǎn)答題答：行為型模式用于描述程序在運(yùn)行時(shí)復(fù)雜的流程控制，即描述多個(gè)類或?qū)ο笾g怎樣相互協(xié)作共同完成單個(gè)對(duì)象都無(wú)法單獨(dú)完成的任務(wù)，它涉及到算法與對(duì)象間職責(zé)的分配。共有11種行為型模式，它們的定義如下：模板方法Template Method模式：定義一個(gè)操作中的算法骨架，而將算法的一些步驟延遲到子類中，使得子類可以不改變?cè)撍惴?gòu)造的情況下重定義該算法的*些特定步驟。策略Strategy模式：定義了一系列算法，并將每個(gè)算法封裝起來(lái)，使他們可以相互替換，且算法的改變不會(huì)影響到使用算法的客戶。命令mand模式

30、：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，使發(fā)出請(qǐng)求的責(zé)任和執(zhí)行請(qǐng)求的責(zé)任分割開(kāi)。職責(zé)鏈Chain of Responsibility模式：把請(qǐng)求從鏈中的一個(gè)對(duì)象傳到下一個(gè)對(duì)象，直到請(qǐng)求被響應(yīng)為止。通過(guò)這種方式去除對(duì)象之間的耦合。狀態(tài)State模式：允許一個(gè)對(duì)象在其部狀態(tài)發(fā)生改變時(shí)改變其行為能力。觀察者Observer模式：多個(gè)對(duì)象間存在一對(duì)多關(guān)系，當(dāng)一個(gè)對(duì)象發(fā)生改變時(shí)，把這種改變通知給其它多個(gè)對(duì)象，從而影響其它對(duì)象的行為。中介者M(jìn)ediator模式：定義一個(gè)中介對(duì)象來(lái)簡(jiǎn)化原有對(duì)象之間的交互關(guān)系，降低系統(tǒng)中對(duì)象間的耦合度，使原有對(duì)象之間不必相互了解。迭代器Iterator模式：提供一種方法來(lái)順序訪問(wèn)聚合對(duì)象

31、中的一系列數(shù)據(jù)，而不暴露聚合對(duì)象的部表示。訪問(wèn)者Visitor模式：在不改變集合元素的前提下，為一個(gè)集合中的每個(gè)元素提供多種訪問(wèn)方式，即每個(gè)元素有多個(gè)訪問(wèn)者對(duì)象訪問(wèn)。備忘錄Memento模式：在不破壞封裝性的前提下，獲取并保存一個(gè)對(duì)象的部狀態(tài)，以便以后恢復(fù)它。解釋器Interpreter模式：提供如何定義語(yǔ)言的文法，以及對(duì)語(yǔ)言句子的解釋方法，即解釋器。答：模板方法的主要優(yōu)點(diǎn)是：它封裝了不變局部，擴(kuò)展可變局部。它把認(rèn)為是不變局部的算法封裝到父類中實(shí)現(xiàn)，而把可變局部算法由子類繼承實(shí)現(xiàn)，便于子類繼續(xù)擴(kuò)展；它在父類中提取了公共的局部代碼，便于代碼復(fù)用；局部方法是由子類實(shí)現(xiàn)的，因此子類可以通過(guò)擴(kuò)展方式增

32、加相應(yīng)的功能，符合開(kāi)閉原則。模板方法的主要缺點(diǎn)是：對(duì)每個(gè)不同的實(shí)現(xiàn)都需要定義一個(gè)子類，這會(huì)導(dǎo)致類的個(gè)數(shù)增加，系統(tǒng)更加龐大，設(shè)計(jì)也更加抽象；父類中的抽象方法由子類實(shí)現(xiàn)，子類執(zhí)行的結(jié)果會(huì)影響父類的結(jié)果，這導(dǎo)致一種反向的控制構(gòu)造，它提高了代碼閱讀的難度。其應(yīng)用實(shí)例有：自己介紹答：策略模式的構(gòu)造圖如下：其應(yīng)用場(chǎng)景有：1一個(gè)系統(tǒng)需要?jiǎng)討B(tài)地在幾種算法中選擇一種時(shí)，可將每個(gè)算法封裝到策略類中；2一個(gè)類定義了多種行為 , 并且這些行為在這個(gè)類的操作中以多個(gè)條件語(yǔ)句的形式出現(xiàn)，可將每個(gè)條件分支移入到它們各自的策略類中以代替這些條件語(yǔ)句；3系統(tǒng)中各算法彼此完全獨(dú)立，且要求對(duì)客戶隱藏具體算法的實(shí)現(xiàn)細(xì)節(jié)時(shí)；4系統(tǒng)要求

33、使用算法的客戶不應(yīng)該知道其操作的數(shù)據(jù)時(shí)，可使用策略模式來(lái)隱藏與算法相關(guān)的數(shù)據(jù)構(gòu)造；5多個(gè)類只區(qū)別在表現(xiàn)行為不同，可以使用策略模式，在運(yùn)行時(shí)動(dòng)態(tài)選擇具體要執(zhí)行的行為。答：接口定義了增加add、刪除remove、修改set、查詢inde*Of等策略，其實(shí)現(xiàn)類ArrayList、LinkedList等采用了不同的算法來(lái)實(shí)現(xiàn)這些策略，用戶可根據(jù)其特點(diǎn)選用它們。答：命令模式通常適用以下場(chǎng)景：1當(dāng)系統(tǒng)需要將請(qǐng)求調(diào)用者與請(qǐng)求接收者解耦時(shí)，命令模式使得調(diào)用者和接收者不直接交互；2當(dāng)系統(tǒng)需要隨機(jī)請(qǐng)求命令或經(jīng)常增加或刪除命令時(shí)，命令模式比擬方便實(shí)現(xiàn)這些功能；3當(dāng)系統(tǒng)需要執(zhí)行一組操作時(shí)，命令模式可以定義宏命令來(lái)實(shí)現(xiàn)

34、該功能；4當(dāng)系統(tǒng)需要支持命令的撤銷(Undo)操作和恢復(fù)(Redo)操作時(shí)，可以將命令對(duì)象存儲(chǔ)起來(lái)，采用備忘錄模式來(lái)實(shí)現(xiàn)。其應(yīng)用實(shí)例有：自己舉例答：將命令模式與前面學(xué)的組合模式聯(lián)合使用，這就構(gòu)成了宏命令模式，也叫組合命令模式，其具體構(gòu)造圖如下：編程題解：1此題使用了策略模式2其參考程序代碼如下所示： interface TravelStrategy public void travel(); class AirplaneStrategy implements TravelStrategy public void travel() System.out.println(飛機(jī)游！); class

35、TrainStrategy implements TravelStrategy public void travel() System.out.println(火車游！); class BicycleStrategy implements TravelStrategy public void travel() System.out.println(自行車游！); class Person private TravelStrategy ts; public setStrategy(TravelStrategy ts) this.ts=ts; public void travelMethod()

36、Method(); class Client public static void main(String args) TravelStrategy ts = new BicycleStrategy； Person p1 = new Person(); p1.setStrategy(ts); P1.travelMethod(); 第7章行為型模式中7.1 職責(zé)鏈模式7.2 狀態(tài)模式7.3 觀察者模式7.4 中介者模式單項(xiàng)選擇擇題( B ) 2. C 3. ( D ) 4( D ) 5( B ) 6( C ) 7. ( D ) 8. C 多項(xiàng)選擇擇題( A,B,D ) 2. (

37、 A,C,D ) 3. A、B、C 4( A,B,D ) 5( B,C,D ) 填空題對(duì)象行為型純的職責(zé)鏈模式、不純的職責(zé)鏈模式環(huán)境Conte*t、抽象狀態(tài)State、具體狀態(tài)ConcreteState觀察者、命令、不定義中介者接口，把具體中介者對(duì)象實(shí)現(xiàn)成為單例設(shè)計(jì)題1解：此題可使用觀察者模式，參考類圖如下所示：簡(jiǎn)答題答：職責(zé)鏈模式的定義：為了防止請(qǐng)求發(fā)送者與多個(gè)請(qǐng)求處理者耦合在一起，將所有請(qǐng)求的處理者通過(guò)前一對(duì)象記住其下一個(gè)對(duì)象的引用而連成一條鏈；當(dāng)有請(qǐng)求發(fā)生時(shí)，可將請(qǐng)求沿著這條鏈傳遞，直到有對(duì)象處理它為止。答：職責(zé)鏈模式是一種對(duì)象行為型模式，其主要優(yōu)點(diǎn)有：降低了對(duì)象之間的耦合度。該模式使得

38、一個(gè)對(duì)象無(wú)需知道到底是哪一個(gè)對(duì)象處理其請(qǐng)求以及鏈的構(gòu)造，發(fā)送者和接收者也無(wú)需擁有對(duì)方的明確信息。增強(qiáng)了系統(tǒng)的可擴(kuò)展性?？梢愿鶕?jù)需要增加新的請(qǐng)求處理類，滿足開(kāi)閉原則；增強(qiáng)了給對(duì)象指派職責(zé)的靈活性。當(dāng)工作流程發(fā)生變化，可以動(dòng)態(tài)地改變鏈的成員或者調(diào)動(dòng)它們的次序，也可動(dòng)態(tài)地新增或者刪除責(zé)任。職責(zé)鏈簡(jiǎn)化了對(duì)象之間的連接。每個(gè)對(duì)象只需保持一個(gè)指向其后繼者的引用，不需保持其它所有處理者的引用，這防止了使用眾多的if或者if-else語(yǔ)句。責(zé)任分擔(dān)。每個(gè)類只需要處理自己該處理的工作，不該處理的傳遞給下一個(gè)對(duì)象完成，明確各類的責(zé)任圍，符合類的單一職責(zé)原則。其主要缺點(diǎn)是：不能保證每個(gè)請(qǐng)求一定被處理。由于一個(gè)請(qǐng)求沒(méi)

39、有明確的接收者，所以不能保證它一定會(huì)被處理，該請(qǐng)求可能一直傳到鏈的末端都得不到處理；對(duì)于比擬長(zhǎng)的職責(zé)鏈，請(qǐng)求的處理可能涉及到多個(gè)處理對(duì)象，系統(tǒng)性能將受到一定影響；職責(zé)鏈建立的合理性要靠客戶端來(lái)保證，增加了程序的復(fù)雜性，可能會(huì)由于職責(zé)鏈的錯(cuò)誤設(shè)置而導(dǎo)致系統(tǒng)出錯(cuò)，如：可能會(huì)造成循環(huán)調(diào)用。答：通常在以下情況下可以考慮使用狀態(tài)模式：1當(dāng)一個(gè)對(duì)象的行為取決于它的狀態(tài)，并且它必須在運(yùn)行時(shí)刻根據(jù)狀態(tài)改變它的行為時(shí)，就可以考慮使用狀態(tài)模式；2一個(gè)操作中含有龐大的分支構(gòu)造，并且這些分支決定于對(duì)象的狀態(tài)時(shí)。在有些情況下，可能有多個(gè)環(huán)境對(duì)象需要共享一組狀態(tài)，這時(shí)需要引入享元模式，將這些具體狀態(tài)對(duì)象放在集合中供程序共

40、享，這就是共享狀態(tài)模式。答：觀察者模式又叫做發(fā)布-訂閱Publish/Subscribe模式、模型-視圖Model/View模式、源-監(jiān)聽(tīng)器Source/Listener模式或附屬者Dependents模式。答：觀察者模式是基于目標(biāo)對(duì)象的狀態(tài)發(fā)生變化，而促使觀察者對(duì)象作出相應(yīng)操作的一種行為型模式。如，一個(gè)天氣系統(tǒng)，當(dāng)天氣變化時(shí)，展示給公眾的視圖中會(huì)有所反映，這里的天氣是目標(biāo)，而視圖是觀察者。答：中介者模式包含：抽象中介者M(jìn)ediator角色、具體中介者ConcreteMediator角色、抽象同事類Colleague角色、具體同事類ConcreteColleague角色。其構(gòu)造圖如下：綜合題1

41、解：對(duì)于描述1)可以選擇使用工廠方法模式，對(duì)于描述2)可以選擇使用觀察者模式，參考類圖如下所示：在類圖中，HouseCreator是抽象房屋工廠類，其子類VilladomCreator用于創(chuàng)立別墅 Villadom，子類ApartmentCreator用于創(chuàng)立公寓Apartment，Villadom和Apartment都是抽象房屋類House的子類，此時(shí)應(yīng)用了工廠方法模式，如果增加新類型的房屋，只需對(duì)應(yīng)增加新的房屋工廠類即可，原有代碼無(wú)須做任何修改；House類同時(shí)作為抽象觀察目標(biāo)，子類 Villadom和Apartment作為具體觀察目標(biāo)，相關(guān)人員類Stakeholder作為抽象觀察者，其子

42、類Manager主管作為具體觀察者，實(shí)現(xiàn)了在Stakeholder中聲明的response()方法，當(dāng)房屋售出時(shí)，房屋的狀態(tài)status將發(fā)生變化，在setStatus()方法中調(diào)用觀察者的 response()方法，即主管將收到相應(yīng)消息，此時(shí)應(yīng)用了觀察者模式。2解：對(duì)于描述1)可以選擇使用中介者模式，對(duì)于描述2)可以選擇使用適配器模式，參考類圖如下所示：在類圖中，各類的角色如下：旅游公司：抽象中介者；廣之旅：具體中介者；大學(xué)生：抽象同事類；學(xué)院學(xué)生：是具體同事類，也是目標(biāo)抽象類；哈佛大學(xué)生、墨爾本大學(xué)生：是具體同事類，也是適配者類；翻譯1、翻譯2：適配器類。3.解：1要完成以上功能，需使用職

43、責(zé)鏈模式和代理模式；其參考類圖如下所示：在以上類圖中，用到了2種模式： a職責(zé)鏈模式，其中學(xué)校類是抽象處理者，初級(jí)學(xué)校類、中級(jí)學(xué)校類、高級(jí)學(xué)校類是具體處理者，學(xué)員類是請(qǐng)求類； b代理模式，其中效勞器類是抽象主題類，代理效勞器類是代理主題類，遠(yuǎn)程效勞器類是真實(shí)主題類，學(xué)員類是客戶類。第8章行為型模式下迭代器模式訪問(wèn)者模式備忘錄模式解釋器模式單項(xiàng)選擇擇題( C ) 2( B ) 3. C 4. ( B ) 多項(xiàng)選擇擇題( C ) 2. ( A,B,C,D ) 3. ( A,B,C,D ) 簡(jiǎn)答題答：迭代器模式主要包含以下角色：抽象聚合Aggregate角色；具體聚合ConcreteAggregat

44、e角色；抽象迭代器Iterator角色；具體迭代器ConcreteIterator角色。其構(gòu)造圖如下：答：訪問(wèn)者Visitor模式的定義：將作用于*種數(shù)據(jù)構(gòu)造中的各元素的操作別離出來(lái)封裝成獨(dú)立的類，使其在不改變數(shù)據(jù)構(gòu)造的前提下可以添加作用于這些元素的新的操作，為數(shù)據(jù)構(gòu)造中的每個(gè)元素提供多種訪問(wèn)方式。其主要優(yōu)點(diǎn)有：1擴(kuò)展性好。能夠在不修改對(duì)象構(gòu)造中的元素的情況下，為對(duì)象構(gòu)造中的元素添加新的功能；2復(fù)用性好?？梢酝ㄟ^(guò)訪問(wèn)者來(lái)定義整個(gè)對(duì)象構(gòu)造通用的功能，從而提高系統(tǒng)的復(fù)用程度；3靈活性好。訪問(wèn)者模式將數(shù)據(jù)構(gòu)造與作用于構(gòu)造上的操作解耦，使得操作集合可相對(duì)自由地演化而不影響系統(tǒng)的數(shù)據(jù)構(gòu)造；4符合單一職責(zé)原則。其主要缺點(diǎn)是：1增加新的元素類很困難。在訪問(wèn)者模式中，每增加一個(gè)新的元素類，都要在每一個(gè)具體訪問(wèn)者類中增加相應(yīng)的具體操作，這違背了開(kāi)閉原則；2破壞封裝。訪問(wèn)者模式中具體元素對(duì)訪問(wèn)者公布細(xì)節(jié)，這破壞了對(duì)象的封裝性；3違反了依賴倒置原則。訪問(wèn)者模式依賴了具體類，而沒(méi)有依賴抽象類。答：忘錄模式的應(yīng)用場(chǎng)景如下