青島理工大學軟件設計與體系結(jié)構(gòu)期末復習題及參考答案

一、 選擇題1、 關(guān)于微軟的三層架構(gòu)，下列說法錯誤的是：A、分層的目的是為了實現(xiàn)“高內(nèi)聚、低耦合”；B、采用“分而治之”的思想，把任務劃分成子任務；C、唯一的缺陷是降低了代碼的可復用性；D、易于控制，易于延展，易于多人進行項目合作。2、關(guān)于用戶故事，下列說法不恰當?shù)氖牵篈、用戶故事就是正在進行的關(guān)于需求談話的助記符；B、是一個計劃工具；C、用戶故事分解需求，一個用戶故事就是一個小的需求模塊；D、“點數(shù)”能精確其實現(xiàn)代價。3、關(guān)于測試驅(qū)動開發(fā)，下述各項正確的是：A、編寫所有產(chǎn)品代碼的目的都是為了使失敗的單元測試能夠通過；B、編寫完代碼后必須馬上編寫單元測試C、能夠促使模塊之間加強耦合；D、防止模塊之間隔離。4、關(guān)于計劃游戲，下述說法不恰當?shù)氖牵篈、計劃游戲的本質(zhì)是劃分業(yè)務人員和開發(fā)人員之間的職責；B、開發(fā)人員決定選擇哪些用戶故事C、開發(fā)人員基于上次迭代，為客戶提供一個“預算”；D、跟蹤速度是最為重要的管理手段之一。5、關(guān)于簡單設計，下列說法錯誤的是：A、用最簡單的辦法實現(xiàn)每個小需求，前提是按照這些簡單設計開發(fā)出來的軟件必須通過測試。B、設計只要能滿足系統(tǒng)和客戶在當下的需求就可以了，不需要任何畫蛇添足的設計，而且所有這些設計都將在后續(xù)的開發(fā)過程中被不斷地重整和優(yōu)化。C、對于設計結(jié)構(gòu)必須足夠簡單/靈活，適應未來需求變化；D、絕不能容忍重復的代碼。6、關(guān)于軟件重構(gòu)，下列說法不恰當?shù)氖牵篈、重構(gòu)是在不改變代碼外在行為的前提下對代碼做出修改，以改進代碼的內(nèi)部結(jié)構(gòu)的過程。B、每個改造都是微不足道的，但是這些所有的改造迭加在一起，就形成了對系統(tǒng)設計和架構(gòu)顯著的改進。C、每次重構(gòu)進行完后，必須運行單元測試；D、重構(gòu)耗時費力，不宜頻繁進行。7、關(guān)于軟件設計臭味，下列說法錯誤的是：A、僵化性是指軟件運行性能很差；B、如果設計中包含有當前沒有用的組成部分，它就包含不必要的復雜性；C、晦澀性是指模塊難以理解；D、不能因為設計的退化去責怪需求的變化。8、關(guān)于依賴倒置原則，下列說法不恰當?shù)氖牵篈、高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象；B、抽象應該依賴于細節(jié)；C、要針對接口編程，不要針對實現(xiàn)編程；D、任何變量都不應該指向具體類。9、關(guān)于迪米特法則，下列說法錯誤的是：A、一個對象應當對其他對象有盡可能少的了解；B、每一個軟件單位對其它的單位都只有最少的知識，而且僅局限于那些與本單位密切相關(guān)的軟件單位。C、迪米特法則的核心觀念就是類間解耦，雖然解耦會部分降低類的復用性，但是可以很好的避免僵化性；D、陌生的類最好不要作為局部變量的形式出現(xiàn)在類的內(nèi)部。10、關(guān)于職責鏈模式，下列說法不正確的是：A、職責鏈可以是一條直線、一個環(huán)或者一個樹形結(jié)構(gòu)；B、避免將一個請求的發(fā)送者與接收者耦合在一起C、不純的職責鏈：一個具體處理者對象只能在兩個行為中選擇一個--要么承擔全部責任，要么將責任推給下家；職責鏈模式給對象職責的分配帶來更多的靈活性。11、為了能成功地實施XP，XP制定的四個準則不包括：A、文檔B、簡單C、反饋D、勇氣12、關(guān)于用戶故事，下列說法正確的是：A、用戶故事就是正在開發(fā)的項目的腳本；B、是一個可行性分析工具；C、用戶故事分解需求，一個用戶故事就是一個小的需求模塊；D、“點數(shù)”能精確其實現(xiàn)代價。13、關(guān)于代碼重構(gòu)，下面的敘述錯誤的是：A、不斷修改的代碼往往會退化/腐化，導致難于維護，因此需要重構(gòu)。B、每個改造都是微不足道的，但是這些所有的改造迭加在一起，就形成了對系統(tǒng)設計和架構(gòu)顯著的改進。C、每次重構(gòu)進行完后，必須運行單元測試，保證重構(gòu)沒有造成任何破壞，然后再去做下一次重構(gòu)。D、重構(gòu)是對代碼結(jié)構(gòu)的全面優(yōu)化，每次改動往往較大，耗費也較大，因此重構(gòu)頻率不宜過于頻繁。14、關(guān)于工廠方法模式，下述觀點中不合適的是：A、是創(chuàng)建型模式的一種B、核心的工廠類不負責創(chuàng)建對象C、具體工廠類包含業(yè)務邏輯D、工廠類與產(chǎn)品類往往具有平行的等級結(jié)構(gòu)15、關(guān)于職責鏈模式，下列說法不正確的是：A、職責鏈可以是一條直線、一個環(huán)或者一個樹形結(jié)構(gòu)；B、避免將一個請求的發(fā)送者與接收者耦合在一起C、不純的職責鏈：一個具體處理者對象只能在兩個行為中選擇一個--要么承擔全部責任，要么將責任推給下家；D、職責鏈模式給對象職責的分配帶來更多的靈活性。16、微軟推薦的三層架構(gòu)不包括()A、業(yè)務邏輯層B、實體-聯(lián)系層C、數(shù)據(jù)訪問層D、表示層（界面層）17、為了能成功地實施XP，XP制定的四個準則不包括：()A、文檔B、簡單C、反饋D、勇氣18、在XP項目中，關(guān)于代碼重構(gòu)，下面的敘述錯誤的是：()A、不斷修改的代碼往往會退化/腐化，導致難于維護，因此需要重構(gòu)。B、每個改造都是微不足道的，但是這些所有的改造迭加在一起，就形成了對系統(tǒng)設計和架構(gòu)顯著的改進。C、每次重構(gòu)進行完后，必須運行單元測試，保證重構(gòu)沒有造成任何破壞，然后再去做下一次重構(gòu)。D、重構(gòu)是對代碼結(jié)構(gòu)的全面優(yōu)化，每次改動往往較大，耗費也較大，因此重構(gòu)頻率不宜過于頻繁。19、關(guān)于單一職責原則，下述敘述錯誤的是：()A、就一個類而言，應該僅有一個引起它變化的原因。B、過多職責耦合到一起后，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。C、簡言之，就是加大類之間的耦合，減少類內(nèi)部的內(nèi)聚。D、軟件設計真正要做的許多內(nèi)容，就是發(fā)現(xiàn)職責并把那些職責互相分離。20、關(guān)于替代原則，下述敘述錯誤的是：()A、只有父類能完全替代子類才能保證抽象父類的復用和擴展。B、替代原則指導繼承，是繼承的基石。C、對于LSP的違反常常會導致以明顯違反OCP。D、繼承依賴的IS-A關(guān)系是就行為方式而言的。21、關(guān)于依賴倒置原則，下述敘述錯誤的是：()A、高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象。B、抽象不應該依賴于細節(jié)，細節(jié)應該依賴于抽象。C、要針對接口編程，不要針對實現(xiàn)編程。D、高層模塊實現(xiàn)了在低層模塊中聲明并被低層模塊調(diào)用的接口。22、關(guān)于迪米特法則，下述說法中不恰當?shù)氖牵?)A、一個對象應當對其他對象有盡可能少的了解。B、只與你“直接的朋友們”通信。C、迪米特法則的核心觀念就是類間解耦。D、應用符合迪米特法則后，類之間就是弱耦合，從而系統(tǒng)的不同模塊之間的通信效率會相應的提高。23、關(guān)于工廠方法模式，下述觀點中不合適的是：()A、是創(chuàng)建型模式的一種B、核心的工廠類不負責創(chuàng)建對象C、具體工廠類包含業(yè)務邏輯D、工廠類與產(chǎn)品類往往具有平行的等級結(jié)構(gòu)24、關(guān)于原型模式，下述觀點不正確的是：()A、利用.Net中的MemberwiseClone（）可以實現(xiàn)淺表復制B、利用序列化和反序列化不能實現(xiàn)深度復制C、允許動態(tài)增加或減少產(chǎn)品類，增加新產(chǎn)品對整個結(jié)構(gòu)沒有影響D、擴展功能：可以帶有原型管理器25、關(guān)于橋接模式，下述說法不正確的是：()A、將抽象部分與實現(xiàn)部分分離，使它們都可以獨立地變化B、將一個事物中多個維度的變化分離C、Implementor的接口必須與Abstraction的接口相同D、使用“對象間的組合關(guān)系”解耦了抽象和實現(xiàn)之間固有的綁定關(guān)系26、關(guān)于組合模式，下述說法不恰當?shù)氖牵?)A、組合模式中，數(shù)據(jù)之間的關(guān)系是典型的網(wǎng)狀結(jié)構(gòu)B、所有的節(jié)點可以采用一致的處理方法C、安全的組合模式中，實際上違反了接口獨立原則D、透明的組合模式，在實際執(zhí)行過程中，存在隱患。27、關(guān)于裝飾模式，下述說法不恰當?shù)氖牵?)A、動態(tài)地給一個對象增加一些額外的職責B、比單純地使用繼承方式更為靈活C、Decorator和Component的關(guān)系，首先是繼承關(guān)系，然后是組合關(guān)系D、裝飾模式雖然產(chǎn)生的對象數(shù)量較少，但是會生成大量較小的類28、關(guān)于模板方法模式，下述敘述不恰當?shù)氖牵?)A、定義一個操作中的算法的骨架，而將一些步驟的實現(xiàn)延遲到子類中。B、強調(diào)使用組合替代繼承C、將行為盡量移動到結(jié)構(gòu)的高端D、反向控制結(jié)構(gòu)（IoC）是模版方法模式的典型應用29、關(guān)于命令模式，下述說法不正確的是：()A、解決了“行為請求者”與“行為實現(xiàn)者”之間的緊耦合B、將一些行為命令化，參數(shù)化C、可以實現(xiàn)Undo和RedoD、可能造成命令執(zhí)行者對象過多是該模式的主要缺點30、關(guān)于觀察者模式，下述說法不恰當?shù)氖牵?)A、解決的是對象間的一種多對多的依賴關(guān)系B、既要保證對象間的低耦合，又能夠維持行動的協(xié)調(diào)一致，保證高度的協(xié)作C、很好的體現(xiàn)了依賴倒置原則D、在C#的實現(xiàn)方式中，委托定義可以充當抽象的Observer接口二、判斷題1.建造者模式要求復雜對象的各個部分經(jīng)常面臨著劇烈的變化，但是將它們組合在一起的算法卻相對穩(wěn)定。()2.代理模式中，當代理對象將客戶端請求發(fā)送給真實對象之前或之后往往會添加一些額外的操作。()3.在享元模式中，外部狀態(tài)可以共享，但是內(nèi)部狀態(tài)不能共享。()4.外觀模式定義了一個高層接口，這個接口使得復雜子系統(tǒng)更加容易使用。()5.觀察者模式中，如果在被觀察者之間有循環(huán)依賴，可能導致“死鎖”。()6.軟件體系結(jié)構(gòu)設計的一個核心問題是“復用”。()7.實體類實現(xiàn)所謂的對象關(guān)系映射（簡稱ORM），是為了解決面向?qū)ο蟮念惻c關(guān)系數(shù)據(jù)庫的表之間，存在的不匹配的現(xiàn)象。()8.合適的工具對成功來說是重要的，敏捷方法建議選用綜合功能比較全面的工具。()9.極限編程要求每2周發(fā)布一次軟件，稱為一次發(fā)布周期。()10.用戶故事的驗收測試是在就要實現(xiàn)該用戶故事之前或?qū)崿F(xiàn)該用戶故事的同時進行編寫的。()11.放置釣鉤(hook)以適應將來的軟件需求變化，是開放-封閉原則的典型應用。()12.繼承依賴的IS-A關(guān)系是就具體的行為方式而言的。()13.在設計類結(jié)構(gòu)時，組合優(yōu)于繼承。()14.設計模式描述了軟件設計過程中某一類常見問題的一般性的解決方案。()15.簡單工廠模式完全符合開放-封閉原則。()16.在VS中，一個Project可以包含多個Solution。()17.敏捷開發(fā)認為：完備的文檔是保證軟件系統(tǒng)質(zhì)量的重要手段。()18.XP項目實施過程中，每個人應該分工明確，各自簽領(lǐng)自己擅長的任務。()19.在XP中，隱喻通?？梢詺w結(jié)為一個名字系統(tǒng)。()20.在敏捷開發(fā)中，設計和構(gòu)架的過程是持續(xù)不斷的。()21.在代碼中放置“Hook”是開放/封閉原則實施的主要手段。()22.ISP原則認為，接口應該盡可能簡單，一個接口只做一件事情。()23.為減弱類間耦合，LoD提倡多使用序列化（Serialize）功能。()24.簡單工廠模式違反開放/封閉原則，而工廠方法模式符合開放/封閉原則，且完全不需要判斷工廠的類型。()25.相比適配器模式，橋接模式實際上是個“事后諸葛亮”。()三、簡答題簡述實體類的概念及其作用。敏捷開發(fā)宣言。簡述XP的短交付周期的概念。測試驅(qū)動開發(fā)的概念及其積極作用。XP中簡單設計的概念及其指導原則。簡述常見的設計臭味。簡述開放/封閉原則。簡述什么是設計模式。試給出抽象工廠模式的結(jié)構(gòu)圖及其角色描述。10、簡述觀察者模式的定義與結(jié)構(gòu)。11、軟件體系結(jié)構(gòu)的概念及構(gòu)成。12、什么是結(jié)對編程？13、測試驅(qū)動開發(fā)遵循的3條簡單的規(guī)則是什么？簡述適配器模式的定義及對象適配器的結(jié)構(gòu)。15、簡述三層架構(gòu)開發(fā)模式及其優(yōu)點。16、每個軟件模塊都應該具有的三項職責是什么？17、為什么說“源代碼就是設計！”？簡述單一職責原則。簡述依賴倒置原則。什么是面向?qū)ο蟮娜髾C制？21、簡述簡單工廠模式的優(yōu)缺點。22、簡述XP中的完整團隊概念。四、設計題1、試給出多線程安全的“懶漢式”和“餓漢式”單件模式的代碼。2、設計一個命令行狀態(tài)下運行的運算程序，目前支持加減乘除（+，-，*，/）等四則運算，將來還可能添加求余數(shù)(%)運算，請以學過的設計模式設計一個程序結(jié)構(gòu)，先畫出類圖,再寫出代碼。要求：（1）符合開放/封閉原則；（2）業(yè)務邏輯和界面邏輯必須分開；（3）先設計只支持四則運算的程序，再說明如何升級程序加上求余數(shù)（%）運算。3、銀行帳戶改動通知系統(tǒng)：帳戶的余額發(fā)生變化時，需要通過手機短信和E-Mail的方式通知到用戶本人，試用所學過的設計模式實現(xiàn)該系統(tǒng)。要求：（1）指出使用的設計模式的名稱；（2）畫出該設計模式的類結(jié)構(gòu)圖；（3）給出系統(tǒng)模擬實現(xiàn)的代碼；（4）設計符合開放/封閉原則。4.最簡單的手機（SimplePhone）在接收到來電的時候，會發(fā)出聲音提醒主人，現(xiàn)在需要為該手機添加一項功能，即在接收到來電的時候，除了有聲音還能產(chǎn)生震動（JarPhone），還可以得到更高級的手機（ComplexPhone），來電的時候，它不僅能夠發(fā)聲，產(chǎn)生震動，而且有燈光閃爍提示。試用學過的設計模式實現(xiàn)該系統(tǒng)。要求：給出設計模式的名稱及系統(tǒng)結(jié)構(gòu)的類圖。5、什么是開放封閉原則？簡要說明如何實現(xiàn)該原則。分別討論三種工廠模式（簡單工廠、工廠方法和抽象工廠）在不使用反射技術(shù)時，是否支持開放封閉原則。6、在某系統(tǒng)的圖表處理模塊中，需要將圖表（Chart）顯示和圖表數(shù)據(jù)采集（DataCollection）分離，系統(tǒng)可支持多種圖表（如柱狀圖BarChart，餅狀圖PieChart等），也提供了多種數(shù)據(jù)采集方式，例如可以從文本文件中讀取數(shù)據(jù)（TxtDataCollection），也可以從數(shù)據(jù)庫中讀取數(shù)據(jù)（DBDataCollection），還可以從Excel文件中獲取數(shù)據(jù)（ExcelDataCollection），如果需要從Excel文件中獲取數(shù)據(jù)，則需要調(diào)用與Excel相關(guān)的API，例如讀取Excel文件的ExcelReader類，而這個API是現(xiàn)有系統(tǒng)所不具備的。試用學過的2種設計模式來實現(xiàn)該系統(tǒng)。要求：給出設計模式的名稱及系統(tǒng)結(jié)構(gòu)的類圖。

一、選擇題CDABCDABCCACDCCBADCADDCBCADBDA二、判斷題√√X√√√√XX√X√√√XXXXX√√X√XXX三、簡答題1、 簡述實體類的概念及其作用。實體類實現(xiàn)所謂的對象關(guān)系映射（ObjectRelationalMapping，簡稱ORM），是為了解決面向?qū)ο蟮念惻c關(guān)系數(shù)據(jù)庫的表之間，存在的不匹配的現(xiàn)象，通過使用描述對象和關(guān)系之間映射的元數(shù)據(jù)，在程序中的類對象，與關(guān)系數(shù)據(jù)庫的表之間建立持久的關(guān)系，用于在程序中描述數(shù)據(jù)庫表。本質(zhì)上就是將數(shù)據(jù)從一種形式轉(zhuǎn)換到另外一種形式。簡單地說，就是描述一個業(yè)務實體的類。實體類對象是現(xiàn)實世界中實體對象在計算機中的表示，在層與層之間以及層內(nèi)模塊間進行數(shù)據(jù)傳輸。2、敏捷開發(fā)宣言。我們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發(fā)方法，通過這項工作，我們認為：個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應變化勝過遵循計劃雖然右項也有其價值，但我們認為左項更加重要。3、 簡述XP的短交付周期的概念。迭代計劃:XP項目每兩周交付一次可以工作的軟件。每兩周的迭代都實現(xiàn)了利益相關(guān)者的一些需求，在每次迭代結(jié)束時，會給利益相關(guān)者演示迭代生成的系統(tǒng)，以得到他們的反饋。迭代是一次較小的交付，可能會被加入到產(chǎn)品中，也可能不會。每個周期（Iteration）開發(fā)的需求都是用戶最需要的東西。發(fā)布計劃：XP團隊通常會創(chuàng)建一個計劃來規(guī)劃隨后大約6次迭代的內(nèi)容。一次發(fā)布通常需要2-3個月的工作。它表示了一次較大的交付，通常此次交付會被加入到產(chǎn)品中。發(fā)布計劃不是一成不變的，客戶可以隨時改變計劃的內(nèi)容，他可以取消用戶故事，編寫新的用戶故事，或者改變用戶故事的優(yōu)先級別。但是客戶應該更改后面迭代的內(nèi)容，盡量不要更改下一次迭代。4、 測試驅(qū)動開發(fā)的概念及其積極作用。編寫所有產(chǎn)品代碼的目的都是為了使失敗的單元測試能夠通過。首先編寫一個單元測試，由于它要測試的功能還不存在，因此它會運行失敗，然后，編寫代碼使測試通過。編寫測試用例和代碼之間的更迭速度是很快的，基本上在幾分鐘左右。積極的影響：(1)程序中的每一項功能都有測試來驗證它的操作的正確性。(2)首先編寫測試可以迫使我們使用不同的觀察點---程序調(diào)用者的角度，可以設計出便于調(diào)用的軟件(3)通過首先編寫測試，可以迫使自己把程序設計為可測試的，迫使我們解除軟件中的耦合（forceustodecouplethesoftware）(4)測試可以作為一種無價的文檔形式，而且可以提供范例5、XP中簡單設計的概念及其指導原則。XP團隊使他們的設計盡可能地簡單、具有表現(xiàn)力（expressive）。此外，他們僅僅關(guān)注于計劃在本次迭代中要完成的用戶故事。他們不會考慮那些未來的用戶故事。XP要求用最簡單的辦法實現(xiàn)每個小需求，前提是按照這些簡單設計開發(fā)出來的軟件必須通過測試。這些設計只要能滿足系統(tǒng)和客戶在當下的需求就可以了，不需要任何畫蛇添足的設計，而且所有這些設計都將在后續(xù)的開發(fā)過程中被不斷地重整和優(yōu)化。3條XP指導原則：(1)考慮能工作的最簡單的事情盡量考慮最簡單的方法實現(xiàn)當前的用戶故事。(2)你不需要它將來會用到，現(xiàn)在不考慮，不得不用時再添加；(3)一次，并且只有一次極限編程者絕不能容忍重復的代碼6、簡述常見的設計臭味。僵化性是指難以對軟件進行改動，即使簡單的改動；脆弱性是指，在進行一個改動時，程序的許多地方就可能出現(xiàn)問題；牢固性是指，設計中包含了對其他系統(tǒng)有用的部分，但是要把這些部分從系統(tǒng)中分離出來所需要的努力和風險是巨大的；軟件的粘滯性和環(huán)境的粘滯性：當那些可以保持系統(tǒng)設計的方法比那些拼湊手法更難應用的時候，就表明設計具有高的粘滯性，當開發(fā)環(huán)境遲鈍、低效時，就會產(chǎn)生環(huán)境的粘滯性；如果設計中包含有當前沒有用的組成部分，它就包含不必要的復雜性；不必要的重復，剪切和粘貼也許是有用的文本編輯操作，但是它們卻是災難性的代碼編輯操作；晦澀性是指模塊難以理解。7、 簡述開放/封閉原則。開放-封閉原則：軟件實體（類、模塊、函數(shù)等）應該是可以擴展的，但是不可修改。（1）對于擴展是開放的--這意味著模塊的行為是可擴展的。我們可以根據(jù)需求的變化來改變模塊的功能（2）對于修改是封閉的--對模塊行為進行擴展時，不必改動模塊的源代碼或二進制代碼(需要重新編譯即為修改)把一個功能的通用部分和實現(xiàn)細節(jié)清晰的分離開來；通過派生來擴展功能。8、 簡述什么是設計模式。每一個模式描述了一個在我們周圍不斷重復發(fā)生的問題，以及該問題的解決方案的核心。設計模式描述了軟件設計過程中某一類常見問題的一般性的解決方案。--經(jīng)驗性的好的方案面向?qū)ο笤O計模式描述了面向?qū)ο笤O計過程中、特定場景下、類與相互通信的對象之間常見的組織關(guān)系。9、試給出抽象工廠模式的結(jié)構(gòu)圖及其角色描述。所謂的抽象工廠是指一個工廠等級結(jié)構(gòu)可以創(chuàng)建出分屬于不同產(chǎn)品等級結(jié)構(gòu)的一個產(chǎn)品族中的所有對象。抽象工廠（AbstractFactory）角色：擔任這個角色的是工廠方法模式的核心，它是與應用系統(tǒng)商業(yè)邏輯無關(guān)的(給出創(chuàng)建對象的幾個方法的說明)。具體工廠（ConcreteFactory）角色：這個角色直接在客戶端的調(diào)用下創(chuàng)建多個具體產(chǎn)品的實例。這個角色含有選擇合適的產(chǎn)品對象的邏輯，而這個邏輯是與應用系統(tǒng)的商業(yè)邏輯緊密相關(guān)的(實現(xiàn)具體的創(chuàng)建方法)。抽象產(chǎn)品（AbstractProduct）角色：擔任這個角色的類是工廠方法模式所創(chuàng)建的具體對象的父類，或它們共同擁有的接口—給出產(chǎn)品對象業(yè)務上的共同點。具體產(chǎn)品（ConcreteProduct）角色：抽象工廠模式所創(chuàng)建的任何產(chǎn)品對象都是某一個具體產(chǎn)品類的實例。這是客戶端最終需要的東西，其內(nèi)部一定充滿了應用系統(tǒng)的商業(yè)邏輯。10、簡述觀察者模式的結(jié)構(gòu)。定義對象間的一種一對多的依賴關(guān)系，以便當一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并自動更新。抽象主題（Subject）角色：抽象主題角色把所有對觀察考對象的引用保存在一個聚集里，每個主題都可以有任何數(shù)量的觀察者。抽象主題提供一個接口，可以增加和刪除觀察者對象，主題角色又叫做抽象被觀察者（Observable）角色，一般用一個抽象類或者一個接口實現(xiàn)。抽象觀察者（Observer）角色：為所有的具體觀察者定義一個接口，在得到主題的通知時更新自己。這個接口叫做更新接口。抽象觀察者角色一般用一個抽象類或者一個接口實現(xiàn)。在這個示意性的實現(xiàn)中，更新接口只包含一個方法（即Update()方法），這個方法叫做更新方法。具體主題（ConcreteSubject）角色：將有關(guān)狀態(tài)存入具體現(xiàn)察者對象；在具體主題的內(nèi)部狀態(tài)改變時，給所有登記過的觀察者發(fā)出通知。具體主題角色又叫做具體被觀察者角色（ConcreteObservable）。具體主題角色通常用一個具體子類實現(xiàn)。具體觀察者（ConcreteObserver）角色：存儲與主題的狀態(tài)自恰的狀態(tài)。具體現(xiàn)察者角色實現(xiàn)抽象觀察者角色所要求的更新接口，以便使本身的狀態(tài)與主題的狀態(tài)相協(xié)調(diào)。如果需要，具體現(xiàn)察者角色可以保存一個指向具體主題對象的引用。具體觀察者角色通常用一個具體子類實現(xiàn)。11、軟件體系結(jié)構(gòu)的概念及構(gòu)成。答案:軟件體系結(jié)構(gòu)是具有一定形式的結(jié)構(gòu)化元素，即構(gòu)件的集合，包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。處理構(gòu)件負責對數(shù)據(jù)進行加工；數(shù)據(jù)構(gòu)件是被加工的信息；連接構(gòu)件把體系結(jié)構(gòu)的不同部分組合連接起來。12、什么是結(jié)對編程？答案:所有產(chǎn)品（production）代碼都是由結(jié)對的程序員使用同一臺電腦共同完成的，結(jié)對人員中的一位控制鍵盤并輸入代碼，另一位觀察輸入的代碼并尋找著代碼中的錯誤和可以改進的地方。兩人頻繁互換角色，結(jié)對的關(guān)系每天至少改變一次，以便于每個程序員在一天中可以在兩個不同的結(jié)對中工作，“業(yè)務領(lǐng)域?qū)＜摇币残枰c團隊中的其他所有成員結(jié)對。13、測試驅(qū)動開發(fā)遵循的3條簡單的規(guī)則是什么？答案:除非已經(jīng)編寫了一個不能通過的單元測試，否則不編寫任何產(chǎn)品代碼；只要編寫能夠正好導致測試不通過或者編譯失敗的單元測試就夠了，無需再多；只要編寫能夠正好使失敗的單元測試通過的產(chǎn)品代碼就夠了，無需再多。遵循上述原則，以非常短的周期（1-2分鐘）迭代；14、簡述適配器模式的定義及對象適配器的結(jié)構(gòu)。答案:將一個類的接口轉(zhuǎn)換成客戶希望的另一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。15、簡述三層架構(gòu)開發(fā)模式及其優(yōu)點。微軟推薦的三層結(jié)構(gòu)通常是指數(shù)據(jù)訪問層（DAL）、業(yè)務邏輯層（BLL）和表示層（UI）。與網(wǎng)絡協(xié)議的分層一樣，軟件設計也要進行分層，分層的目的是為了實現(xiàn)“高內(nèi)聚、低耦合”，采用“分而治之”的思想，把任務劃分成子任務，逐個解決，易于控制，易于延展，易于多人進行項目合作。優(yōu)點：不必為了業(yè)務邏輯上的微小變化而導至整個程序的修改，只需要修改商業(yè)邏輯層中的一個函數(shù)或一個過程—靈活，適應多變的需求；增強了代碼的可重用性；便于不同層次的開發(fā)人員之間的合作，只要遵循一定的接口標準就可以進行并行開發(fā)了，最終只要將各個部分拼接到一起構(gòu)成最終的應用程序。16、每個軟件模塊都應該具有的三項職責是什么？它運行起來所完成的功能，這也是該模塊得以完成的原因。它要應對變化，幾乎所有的模塊在它們的生命周期中都要變化。開發(fā)者有責任保證這種改變應該盡可能地簡單。它要和閱讀它的人進行溝通。對該模塊不熟悉的開發(fā)人員應該能夠比較容易地閱讀并理解它。17、為什么說“源代碼就是設計！”？軟件項目的設計是一個抽象的概念，它和程序的概觀、結(jié)構(gòu)以及每一個模塊、類和方法的詳情和結(jié)構(gòu)有關(guān)，可以使用許多不同的媒介描繪設計，但是最終的體現(xiàn)為源代碼。Reeves認為：軟件系統(tǒng)的源代碼是它的主要設計文檔。用來描繪源代碼的圖示只是設計的附屬物而不是設計本身。從根本上講，源代碼就是設計！18、簡述單一職責原則。就一個類而言，應該僅有一個引起它變化的原因。在SRP中，我們把職責定義為“變化的原因”（areasonforchange）。軟件設計真正要做的許多內(nèi)容，就是發(fā)現(xiàn)職責并把那些職責互相分離(找到變化點,并封裝之)。事實上，我們將要論述的其余原則都會以這樣或那樣的方式回到這個問題上。19、簡述依賴倒置原則。高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象。抽象不應該依賴于細節(jié)，細節(jié)應該依賴于抽象。要針對接口編程，不要針對實現(xiàn)編程。20、什么是面向?qū)ο蟮娜髾C制？各種面向?qū)ο缶幊陶Z言相互有別，但都能看到它們對面向?qū)ο笕髾C制的支持，即：“封裝、繼承、多態(tài)”封裝，隱藏內(nèi)部實現(xiàn)繼承，復用現(xiàn)有代碼，擴展已有的行為多態(tài)，改寫已有的行為21、簡述簡單工廠模式的優(yōu)缺點。優(yōu)點：工廠類含有必要的判斷邏輯，可以決定在什么時候創(chuàng)建哪一個產(chǎn)品類的實例，客戶端可以免除直接創(chuàng)建產(chǎn)品對象的責任，而僅僅"消費"產(chǎn)品。簡單工廠模式通過這種做法實現(xiàn)了對責任的分割。缺點：當產(chǎn)品有復雜的多層等級結(jié)構(gòu)時，工廠類只有自己，以不變應萬變，就是模式的缺點。因為工廠類集中了所有產(chǎn)品創(chuàng)建邏輯，一旦不能正常工作，整個系統(tǒng)都要受到影響。違反開放/封閉原則:系統(tǒng)擴展困難，一旦添加新產(chǎn)品就不得不修改工廠邏輯，有可能造成工廠邏輯過于復雜。另外，簡單工廠模式通常使用靜態(tài)工廠方法，這使得無法由子類繼承，造成工廠角色無法形成基于繼承的等級結(jié)構(gòu)。22.簡述XP中的完整團隊概念。答案:客戶、管理者和開發(fā)人員應該緊密地工作在一起，以便彼此知曉對方所面臨的問題，并共同去解決這些問題。XP團隊中的客戶是指定義產(chǎn)品的特性并排列這些特性優(yōu)先級的人或者團體。最好的情況是客戶和開發(fā)人員在同一個房間中工作，次一點的情況是客戶和開發(fā)人員之間的距離在100米內(nèi)。如果確實無法和客戶在一起工作，那么就去尋找能夠在一起工作、愿意并能夠代替真正客戶的人。四、設計題1、試給出多線程安全的“懶漢式”和“餓漢式”單件模式的代碼。publicclassSingleton//懶漢式{//唯一的實例對象,每次訪問時重新讀取instance變量的值privatestaticvolatileSingletoninstance=null;privatestaticreadonlyobjectlockHelper=newobject();//輔助加鎖對象privateSingleton()//私有構(gòu)造函數(shù)，防止外部應用使用new方法創(chuàng)建新的實例{}publicstaticSingletonGetInstance()//獲取唯一的實例對象{if(instance==null)//先判斷對象是否存在--這樣做能夠保證執(zhí)行效率！{lock(lockHelper)//加鎖--創(chuàng)建臨界區(qū){if(instance==null)//加鎖后二次判斷，只允許一個線程判斷{instance=newSingleton();}}}returninstance;}}publicclassSingleton//餓漢式{//公共靜態(tài)只讀屬性--依靠系統(tǒng)在加載時進行初始化，對于多線程環(huán)境也是安全的publicstaticreadonlySingletoninstance=newSingleton();privateSingleton()//私有構(gòu)造函數(shù)，防止外部應用使用new方法創(chuàng)建新的實例{}}2、設計一個命令行狀態(tài)下運行的運算程序，目前支持加減乘除（+，-，*，/）等四則運算，將來還可能添加求余數(shù)(%)運算，請以學過的設計模式設計一個程序結(jié)構(gòu)，先畫出類圖,再寫出代碼。要求：（1）符合開放/封閉原則；（2）業(yè)務邏輯和界面邏輯必須分開；（3）先設計只支持四則運算的程序，再說明如何升級程序加上求余數(shù)（%）運算。類圖：代碼：Operation.cs:///<summary>///抽象的運算基類///</summary>publicclassOperation{//二個運算對象privatedouble_numberA;privatedouble_numberB;///<summary>///運算數(shù)A///</summary>publicdoubleNumberA{get{return_numberA;}set{_numberA=value;}}///<summary>///運算數(shù)B///</summary>publicdoubleNumberB{get{return_numberB;}set{_numberB=value;}}//獲取運算結(jié)果，此處為虛方法，子類必須重寫publicvirtualdoubleGetResult(){doubleresult=0;returnresult;}}OperationAdd.cs:///<summary>///加法類，派生自運算類，在GetResult方法中具體實現(xiàn)加法運算///</summary>publicclassOperationAdd:Operation{publicoverridedoubleGetResult()//實現(xiàn)具體的加法運算{doubleresult=0;result=NumberA+NumberB;returnresult;}}與上面的OperationAdd類似有OperationSub、OperationMul和OperationDivOperationFactory.cs：///<summary>///運算對象工廠類///</summary>publicclassOperationFactory{publicstaticOperationCreateOperate(stringoperate)//根據(jù)傳進來的運算符來決定創(chuàng)建什么樣的對象{return(Operation)Assembly.Load("程序集名稱").CreateInstance(轉(zhuǎn)換運算符為類名稱(operate));}}主程序：classProgram{staticvoidMain(string[]args){try{//輸入運算對象和運算符Console.Write("請輸入數(shù)字A：");stringstrNumberA=Console.ReadLine();Console.Write("請輸入運算符（+，-，*，/,%）：");stringstrOperate=Console.ReadLine();Console.Write("請輸入數(shù)字B：");stringstrNumberB=Console.ReadLine();//由工廠創(chuàng)建運算對象Operationoperate=OperationFactory.CreateOperate(strOperate);//設置要運算的數(shù)據(jù)operate.NumberA=Convert.ToDouble(strNumberA);operate.NumberB=Convert.ToDouble(strNumberB);//具體作運算--動態(tài)決定調(diào)用哪個子類的GetResult（）方法doubleresult=operate.GetResult();//顯示運算結(jié)果Console.WriteLine(strNumberA+strOperate+strNumberB+"="+result);Console.ReadLine();}catch(Exceptionex){Console.WriteLine("您輸入的數(shù)據(jù)有錯誤！"+ex.ToString());Console.ReadLine();}}}擴展程序功能：仿照前面的OperationAdd添加支持新運算的類OperationMod，對運算符（%）轉(zhuǎn)換為類名OperationMod作設置改變，重新編譯系統(tǒng)即可。3、銀行帳戶改動通知系統(tǒng)：帳戶的余額發(fā)生變化時，需要通過手機短信和E-Mail的方式通知到用戶本人，試用所學過的設計模式實現(xiàn)該系統(tǒng)。要求：（1）指出使用的設計模式的名稱；（2）畫出該設計模式的類結(jié)構(gòu)圖；（3）給出系統(tǒng)模擬實現(xiàn)的代碼；（4）設計符合開放/封閉原則。答案：使用觀察者模式。代碼：///<summary>///Observer--抽象觀察者接口///</summary>publicinterfaceAccountUpdated{///<summary>///觀察者接收/處理通知的方法///</summary>///<paramname="val">帳戶余額</param>voidBalanceUpdated(doubleval);}///<summary>///具體觀察者--帳戶余額發(fā)生變化時,發(fā)送Email通知用戶///</summary>classEmail:AccountUpdated{///<summary>///接收郵件通知的E-Mail地址///</summary>privatestringEmailAddress;publicEmail(stringaddress){EmailAddress=address;}///<summary>///發(fā)送Email通知操作///</summary>///<paramname="val">余額數(shù)值</param>publicvoidBalanceUpdated(doubleval){Console.WriteLine("發(fā)送郵件到{0},余額為{1}.",EmailAddress,val);}//其他操作相關(guān)的屬性和方法}///<summary>///具體觀察者--帳戶余額發(fā)生變化時,通過手機發(fā)送短信通知用戶///</summary>classMobile:AccountUpdated{///<summary>///接收短信通知的電話號碼///</summary>privatestringPhoneNumber;publicMobile(stringphone){PhoneNumber=phone;}///<summary>///發(fā)送短信通知///</summary>///<paramname="val">余額數(shù)值</param>publicvoidBalanceUpdated(doubleval){Console.WriteLine("發(fā)送短信至手機{0}，余額為{1}.",PhoneNumber,val);}//其他操作相關(guān)的屬性和方法}///<summary>///ConcreteSubject具體主題--銀行帳戶///</summary>classBankAccount:Subject{///<summary>///帳戶余額--subjectState///</summary>privatedoublebalance=0;///<summary>///存入/取出--調(diào)整余額