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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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