軟件設(shè)計(jì)模式終極版復(fù)習(xí)題(共7頁(yè))

1、精選優(yōu)質(zhì)文檔-傾情為你奉上1.簡(jiǎn)述“開(kāi)閉”原則的基本思想。請(qǐng)舉出一個(gè)使用了軟件“開(kāi)閉”原則的軟件設(shè)計(jì)模式，其中何處體現(xiàn)了“開(kāi)閉”原則。答：“開(kāi)閉”原則：軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，而對(duì)修改關(guān)閉，“開(kāi)-閉”原則要求軟件系統(tǒng)能夠在不需要修改原有類(lèi)的基礎(chǔ)上，通過(guò)增加類(lèi)達(dá)到擴(kuò)展功能的目的。Abstract factory體現(xiàn)了這個(gè)原則，如果想增加一類(lèi)新的products，只需在product類(lèi)體系中增加各個(gè)products，然后在factory類(lèi)體系結(jié)構(gòu)中增加一個(gè)concrete factory就可以了，而不需要對(duì)現(xiàn)有類(lèi)做任何修改，The Open-closed principleocp在不改動(dòng)過(guò)模塊源代

2、碼的情況下擴(kuò)展模塊的行為。軟件實(shí)體（類(lèi)模塊 函數(shù)等）應(yīng)該是可以擴(kuò)展的，但是不可以修改的。2.簡(jiǎn)述依賴(lài)?yán)D(zhuǎn)原則的基本思想。請(qǐng)舉出一個(gè)使用了軟件依賴(lài)原則的軟件設(shè)計(jì)模式，其中何處體現(xiàn)了依賴(lài)原則。答：依賴(lài)倒置原則的基本思想是：高層模塊不應(yīng)該依賴(lài)于低層模塊，二者都應(yīng)該依賴(lài)于抽象。抽象不應(yīng)該依賴(lài)于細(xì)節(jié)，細(xì)節(jié)應(yīng)該不依賴(lài)于抽象。Tomplate method就體現(xiàn)了這個(gè)原則，它定義了一個(gè)操作中的算法骨架，而將一些步驟延遲到子類(lèi)中，template method使得子類(lèi)不改變一個(gè)算法的結(jié)構(gòu)，即可重定義該算法的某些特定步驟。 3.什么是單一職責(zé)原則？請(qǐng)舉出一個(gè)使用了單一職責(zé)原則的軟件設(shè)計(jì)模式，其中何處體現(xiàn)了單一職

3、責(zé)原則。答：基本思想：SRP使得一個(gè)類(lèi)或一個(gè)模塊承擔(dān)的責(zé)任盡可能的少，使盡可能少的因素或動(dòng)機(jī)影響該類(lèi)或該模塊，即增大類(lèi)或模塊的內(nèi)聚性，減少其耦合度，SRP是所有原則中最簡(jiǎn)單的之一，也是最難正確運(yùn)用的之一。COMMAND模式體現(xiàn)了SRP原則，大多數(shù)類(lèi)都是一組方法和相應(yīng)的一組變量的結(jié)合，而該模式只是封裝了一個(gè)沒(méi)有任何變量的函數(shù)，它對(duì)函數(shù)的關(guān)注超過(guò)了類(lèi)，將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而可用不同的請(qǐng)求對(duì)客戶(hù)進(jìn)行參數(shù)化。4.軟件復(fù)用可采用類(lèi)的繼承方式和類(lèi)的聚合方式，比較兩者的優(yōu)缺點(diǎn)。答：聚合：一個(gè)對(duì)象擁有另一個(gè)對(duì)象或?qū)α硪粋€(gè)對(duì)象負(fù)責(zé)（即一個(gè)對(duì)象包含另一個(gè)對(duì)象或是另一個(gè)對(duì)象的一部分）并且聚合對(duì)象和其所有具有

4、相同的生命周期（即所謂的“同生共死”關(guān)系）。聚合復(fù)用優(yōu)點(diǎn)：容器類(lèi)僅能通過(guò)被包含對(duì)象的接口來(lái)對(duì)其進(jìn)行訪問(wèn)。“黑盒”復(fù)用，因?yàn)楸话瑢?duì)象的內(nèi)部細(xì)節(jié)對(duì)外是不可見(jiàn)。包裝性好。實(shí)現(xiàn)上的相互依賴(lài)性比較小。每一個(gè)類(lèi)只專(zhuān)注于一項(xiàng)任務(wù)。通過(guò)獲取指定其他的具有相同類(lèi)型的對(duì)象的使用，可以在運(yùn)行期間動(dòng)態(tài)地定義（對(duì)象的）組合。聚合的缺點(diǎn)：導(dǎo)致系統(tǒng)中的對(duì)象過(guò)多 為了能將多個(gè)不同的對(duì)象作為組合塊來(lái)使用，必須仔細(xì)地對(duì)接口進(jìn)行定義。類(lèi)繼承：是一種通過(guò)擴(kuò)展（一個(gè)已有對(duì)象的）實(shí)現(xiàn)，從而獲得新功能的復(fù)用方法。繼承的優(yōu)點(diǎn)：容易進(jìn)行新的實(shí)現(xiàn)，因?yàn)槠浯蠖鄶?shù)可繼承而來(lái) 易于修改或擴(kuò)展那些被復(fù)用的實(shí)現(xiàn)。繼承的缺點(diǎn)：破壞了封裝性，因?yàn)檫@會(huì)將父類(lèi)

5、的實(shí)現(xiàn)細(xì)節(jié)暴露給子類(lèi) “白盒”復(fù)用，因?yàn)楦割?lèi)的內(nèi)部細(xì)節(jié)對(duì)于子類(lèi)而言通常是可見(jiàn)的 當(dāng)父類(lèi)的實(shí)現(xiàn)更改時(shí)，子類(lèi)也不得不隨之更改 從父類(lèi)繼承來(lái)的實(shí)現(xiàn)將不能在運(yùn)行期間進(jìn)行改變。5.畫(huà)出工廠方法模式的結(jié)構(gòu)圖。什么情況下適合使用工廠方發(fā)模式？其中product：為工廠模式所要?jiǎng)?chuàng)建的對(duì)象類(lèi)型定義一個(gè)接口。Concrete product:實(shí)現(xiàn)product接口。Creator：聲明工廠方法（factory method）返回值為product的一個(gè)對(duì)象。Concrete creator：覆寫(xiě)factory Method()，返回值為concrete product 的一個(gè)具體實(shí)例。在下面情況下你可以考慮使用工

6、廠方法模式： 1) 當(dāng)客戶(hù)程序不需要知道要使用對(duì)象的創(chuàng)建過(guò)程。 2) 客戶(hù)程序使用的對(duì)象存在變動(dòng)的可能，或者根本就不知道使用哪一個(gè)具體的對(duì)象。6.畫(huà)出合成模式（Composite）的結(jié)構(gòu)圖。舉例說(shuō)明一個(gè)可以應(yīng)用合成模式的軟件設(shè)計(jì)實(shí)例，說(shuō)明其中各角色的作用。實(shí)例：計(jì)算機(jī)和立體組合音響這樣的設(shè)備經(jīng)常被組裝成一部分整體層次結(jié)構(gòu)或者是容器層次結(jié)構(gòu)，例如：底盤(pán)可以包含驅(qū)動(dòng)裝置和平面板，總線含有多個(gè)插件，機(jī)柜包括底盤(pán)、總線等。這樣結(jié)構(gòu)很自然的用composite模式進(jìn)行模擬。Equipment類(lèi)為在部分整體層次結(jié)構(gòu)中的所有設(shè)備定義一個(gè)接口。Equipment聲明一些操作返回一個(gè)設(shè)備的屬性，例如它的能是消耗

7、和價(jià)格。子類(lèi)為指定的設(shè)備實(shí)現(xiàn)了這些操作，Equipment還聲明了一個(gè)Create Iterator 操作，該操作為訪問(wèn)它的零件返回一個(gè)Iterator ,這個(gè)操作的缺省實(shí)現(xiàn)返回一上NullIterator，它在空集上迭代。Composite Equipment是包含其它設(shè)備的基類(lèi)，它也是Equipment的子類(lèi)。7.簡(jiǎn)述門(mén)面模式（Facade）和中介者模式（Mediator）的基本思想，兩者的差異何在？答：門(mén)面模式（facade）又稱(chēng)外觀模式?；舅枷耄簽樽酉到y(tǒng)中的一組接口提供一個(gè)一致的界面， Facade模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。“中介者模式”基本思想：M

8、ediator Pattern 中文譯為“中介者模式”、“調(diào)停者模式”。調(diào)停者模式的定義是：用一個(gè)調(diào)停對(duì)象來(lái)封裝一系列的對(duì)象交互。調(diào)停者使各對(duì)象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。簡(jiǎn)單點(diǎn)來(lái)說(shuō)，將原來(lái)兩個(gè)直接引用或者依賴(lài)的對(duì)象拆開(kāi)，在中間加入一個(gè)“調(diào)?！睂?duì)象，使得兩頭的對(duì)象分別和“調(diào)?！睂?duì)象引用或者依賴(lài)。兩者的差異： 從目的上看，調(diào)停者模式與門(mén)面模式有些相似。 但是門(mén)面模式是介于客戶(hù)程序與子系統(tǒng)之間的，而調(diào)停者模式是介于子系統(tǒng)與子系統(tǒng)之間的。這也注定了它們有很大的區(qū)別：門(mén)面模式是將原有的復(fù)雜邏輯提取到一個(gè)統(tǒng)一的接口，簡(jiǎn)化客戶(hù)對(duì)邏輯的使用。它是被客戶(hù)所感知的，

9、而原有的復(fù)雜邏輯則被隱藏了起來(lái)。而調(diào)停者模式的加入并沒(méi)有改變客戶(hù)原有的使用習(xí)慣，它是隱藏在原有邏輯后面的，使得代碼邏輯更加清晰可用。8.簡(jiǎn)述觀察者模式的基本思想，如何實(shí)現(xiàn)當(dāng)目標(biāo)對(duì)象發(fā)生變化時(shí)多個(gè)觀察者對(duì)象的同步更新？畫(huà)出他們之間的協(xié)作圖。（1）Observer（觀察者）基本思想：對(duì)象間的一種一對(duì)多的依賴(lài)關(guān)系。當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生變化時(shí)，所有依賴(lài)于它的對(duì)象都得到通知并自動(dòng)更新。（2）協(xié)作：當(dāng)Concrete Subject發(fā)生任何可能導(dǎo)到其參觀者與其本身狀態(tài)不一致的改變時(shí)，它將通知它的各個(gè)觀察者。在得到一個(gè)具體的目標(biāo)改變通知后，Concrete Object對(duì)象可向目標(biāo)對(duì)象查詢(xún)信息，Concre

10、te Object使用這個(gè)些信息以使它的狀態(tài)與目標(biāo)對(duì)象的狀態(tài)一致。（3）協(xié)作圖：9.舉一適合使用State模式的例子。與不使用該模式相比，有哪些優(yōu)點(diǎn)？舉例：抽象狀態(tài)類(lèi)定義了一個(gè)抽象方法“寫(xiě)程序”與不使用該模式相比優(yōu)點(diǎn)：State模式將特定的狀態(tài)相關(guān)的行為封裝在一個(gè)類(lèi)中，由于所有狀態(tài)相關(guān)的代碼都存在于某個(gè)concrete state中，所以通過(guò)定義新的子類(lèi)可以很容易的增加新的狀態(tài)和轉(zhuǎn)換。10.有哪些模式的使用可以使得類(lèi)的復(fù)用性增強(qiáng)？說(shuō)明你的理由。策略模式（strategy） 屬于對(duì)象行為型模式，主要定義一系列的算法，把這些算法一個(gè)個(gè)封裝成擁有共同接口的單獨(dú)的類(lèi)，并使他們之間互換，客戶(hù)端調(diào)用他們的

11、時(shí)候互不影響。算法使用和算法分離，即將變化的具體算法封裝起來(lái)，降低了代碼的耦合度，算法提取起來(lái)，使算法得到重用。中介者模式（mediator） 用一個(gè)調(diào)停對(duì)象來(lái)封裝一系列的對(duì)象交互。調(diào)停者使各對(duì)象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。即，將原來(lái)的兩個(gè)直接引用或者依賴(lài)的對(duì)象拆開(kāi)，在中間加入一個(gè)“調(diào)停”對(duì)象，使得兩頭的對(duì)象分別和“調(diào)?！睂?duì)象引用或者依賴(lài)。提高了原有系統(tǒng)的可讀性，將原有系統(tǒng)的多對(duì)多轉(zhuǎn)化為一對(duì)多，提高了代碼的可復(fù)用性。適配器（Adapter）模式 是的原本由于接口不兼容而不能再一起的那些類(lèi)可以一起工作。如畫(huà)圖程序中，已實(shí)現(xiàn)繪制點(diǎn)，直線等功能。為了讓客

12、戶(hù)程序在使用的時(shí)候不用關(guān)心不同定義，定義個(gè)抽象類(lèi)規(guī)范接口，當(dāng)去實(shí)現(xiàn)繪圖時(shí)，發(fā)現(xiàn)系統(tǒng)其它地方已有制圖實(shí)現(xiàn)，但是系統(tǒng)已有的方法與抽象類(lèi)中規(guī)定方法不一樣，這時(shí)候用適配器模式可以解決這問(wèn)題。適配器模式是為了面向接口編程中更好的復(fù)用。11.比較Adapter和Proxy模式使用上的異同之處。適配器模式(Adapter)：將一個(gè)類(lèi)的接口轉(zhuǎn)換成客戶(hù)希望的另外一個(gè)接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些類(lèi)可以一起工作。代理模式有兩個(gè)英文名字：Proxy Pattern 和 Surrogate Pattern。代理模式：為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn)。說(shuō)白了就是，在一些

13、情況下客戶(hù)不想或者不能直接引用一個(gè)對(duì)象，而代理對(duì)象可以在客戶(hù)和目標(biāo)對(duì)象之間起到中介作用，去掉客戶(hù)不能看到的內(nèi)容和服務(wù)或者增添客戶(hù)需要的額外服務(wù)。兩者的主要區(qū)別在于代理模式應(yīng)用的情況是不改變接口命名的，而且是對(duì)已有接口功能的一種控制；而適配器模式則強(qiáng)調(diào)接口轉(zhuǎn)換。 12.說(shuō)明Observer模式的基本實(shí)現(xiàn)方式。如果不用該模式，要達(dá)到同樣的效果，你會(huì)如何做？觀察者模式在關(guān)于目標(biāo)角色、觀察者角色通信的具體實(shí)現(xiàn)中，有兩個(gè)版本。一種情況便是目標(biāo)角色在發(fā)生變化后，僅僅告訴觀察者角色“我變化了”；觀察者角色如果想要知道具體的變化細(xì)節(jié)，則就要自己從目標(biāo)角色的接口中得到。這種模式被很形象的稱(chēng)為：拉模式就是說(shuō)變化的

14、信息是觀察者角色主動(dòng)從目標(biāo)角色中“拉”出來(lái)的。 還有一種方法，那就是我目標(biāo)角色“服務(wù)一條龍”，通知你發(fā)生變化的同時(shí)，通過(guò)一個(gè)參數(shù)將變化的細(xì)節(jié)傳遞到觀察者角色中去。這就是“推模式”管你要不要，先給你啦。 這兩種模式的使用，取決于系統(tǒng)設(shè)計(jì)時(shí)的需要。如果目標(biāo)角色比較復(fù)雜，并且觀察者角色進(jìn)行更新時(shí)必須得到一些具體變化的信息，則“推模式”比較合適。如果目標(biāo)角色比較簡(jiǎn)單，則“拉模式”就很合適。 如果不使用該模式，可采用策略模式，將不同的情況作為子類(lèi)封裝在一個(gè)類(lèi)中,模擬observer模式中目標(biāo)角色的不同狀態(tài)，當(dāng)外部狀態(tài)發(fā)生變化時(shí)，可以選擇不同的strategy1、strategy2改變觀察者角色，從而達(dá)到

15、與觀察者模式同樣的效果。13.請(qǐng)列舉一個(gè)使用裝飾模式的例子。畫(huà)出你的例子的類(lèi)圖結(jié)構(gòu)。JUnit 中的裝飾模式：在 JUnit 中，TestCase 是一個(gè)很重要的類(lèi)，允許對(duì)其進(jìn)行功能擴(kuò)展。 在 junit.extensions 包中，TestDecorator、RepeatedTest 便是對(duì) TestCase 的裝飾模式擴(kuò)展。下面我們將它們和上面的角色對(duì)號(hào)入座。14.列舉兩個(gè)可以使我們?cè)诔绦蛑胁槐厥褂胕felse結(jié)構(gòu)的軟件設(shè)計(jì)模式。使用軟件設(shè)計(jì)模式是如何做到這一點(diǎn)的？策略模式（strategy）和狀態(tài)模式（state）策略模式是將不同算法（處理方法）封裝到stategy類(lèi)中，狀態(tài)模式是將不同

16、狀態(tài)封裝到state類(lèi)中。二者都是通過(guò)，類(lèi)中的子類(lèi)，實(shí)現(xiàn)不同情況的調(diào)用，從而有效的替換充滿(mǎn)在程序中的 if else 語(yǔ)句。15.你認(rèn)為在Linux平臺(tái)上直接運(yùn)行WIN32程序有可能嗎？如認(rèn)為不可能請(qǐng)說(shuō)明理由；如認(rèn)為可能應(yīng)如何實(shí)現(xiàn)這一目標(biāo)？（1）兩個(gè)OS內(nèi)部實(shí)現(xiàn)有很大差別，甚至連路徑的分隔符都不一樣，一個(gè)WIN32程序無(wú)論如何到了最后也要調(diào)用Window api，而這些api在linux上根本沒(méi)有實(shí)現(xiàn)（2）例如：就用戶(hù)界面來(lái)說(shuō)，有些windows的控件，在Linux上根本連對(duì)應(yīng)的具有類(lèi)似功能的控件都沒(méi)有怎么執(zhí)行？如果再涉及進(jìn)程，線程就更復(fù)雜了，差距也更大，如果想用一個(gè)win32程序在linux上執(zhí)行，必須有一個(gè)間接層來(lái)緩和二者差距，然后要求WIN32程序只能調(diào)用這個(gè)間接層里面的庫(kù)函數(shù)16. Java是一個(gè)跨平臺(tái)的軟件語(yǔ)言。為了實(shí)現(xiàn)跨平臺(tái)，你認(rèn)為采用哪種軟件模式來(lái)實(shí)現(xiàn)跨平臺(tái)部分更合理？說(shuō)明你的理由。答：abstract factory實(shí)現(xiàn)跨平臺(tái)比較合適。用abstract factory提供一個(gè)高層接口，來(lái)建造每個(gè)所需的Product，當(dāng)然具體的實(shí)現(xiàn)要用Concrete factory來(lái)實(shí)現(xiàn)，然后讓每個(gè)os對(duì)應(yīng)一個(gè)Concrete factory，這樣當(dāng)其它的Java類(lèi)庫(kù)需要