一、選擇題

1、關于微軟的三層架構，下列說法錯誤的是：

A、分層的目的是為了實現“高內聚、低耦合”；

B、采用“分而治之”的思想，把任務劃分成子任務；

C、唯一的缺陷是降低了代碼的可復用性；

D、易于控制，易于延展，易于多人進行項目合作。

2、關于用戶故事，下列說法不恰當的是：

A、用戶故事就是正在進行的關于需求談話的助記符；

B、是一個計劃工具；

C、用戶故事分解需求，一個用戶故事就是一個小的需求模塊；

D、“點數”能精確其實現代價。

3、關于測試驅動開發，下述各項正確的是：

A、編寫所有產品代碼的目的都是為了使失敗的單元測試能夠通過；

B、編寫完代碼后必須馬上編寫單元測試

C、能夠促使模塊之間加強耦合；

D、防止模塊之間隔離。

4、關于計劃游戲，下述說法不恰當的是：

A、計劃游戲的本質是劃分業務人員和開發人員之間的職責；

B、開發人員決定選擇哪些用戶故事

C、開發人員基于上次迭代，為客戶提供一個“預算”；

D、跟蹤速度是最為重要的管理手段之一。

5、關于簡單設計，下列說法錯誤的是：

A、用最簡單的辦法實現每個小需求，前提是按照這些簡單設計開發出來的軟件必須

通過測試。

B、設計只要能滿足系統和客戶在當下的需求就可以了，不需要任何畫蛇添足的設

計，而且所有這些設計都將在后續的開發過程中被不斷地重整和優化。

C、對于設計結構必須足夠簡單/靈活，適應未來需求變化；

D、絕不能容忍重復的代碼。

6、關于軟件重構，下列說法不恰當的是：

A、重構是在不改變代碼外在行為的前提下對代碼做出修改，以改進代碼的內部結構

的過程。

B、每個改造都是微不足道的，但是這些所有的改造迭加在一起，就形成了對系統設

計和架構顯著的改進。

C、每次重構進行完后，必須運行單元測試；

D、重構耗時費力，不宜頻繁進行。

7、關于軟件設計臭味，下列說法錯誤的是：

A、僵化性是指軟件運行性能很差；

B、如果設計中包含有當前沒有用的組成部分，它就包含不必要的復雜性；

C、晦澀性是指模塊難以理解；

D、不能因為設計的退化去責怪需求的變化。

8、關于依賴倒置原則，下列說法不恰當的是：

A、高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象；

B、抽象應該依賴于細節；

C、要針對接口編程，不要針對實現編程；

D、任何變量都不應該指向具體類。

9、關于迪米特法則，下列說法錯誤的是：

A、一個對象應當對其他對象有盡可能少的了解；

B、每一個軟件單位對其它的單位都只有最少的知識，而且僅局限于那些與本單位密

切相關的軟件單位。

C、迪米特法則的核心觀念就是類間解耦，雖然解耦會部分降低類的復用性，但是可

以很好的避免僵化性；

D、陌生的類最好不要作為局部變量的形式出現在類的內部。

10、關于職責鏈模式，下列說法不正確的是：

A、職責鏈可以是一條直線、一個環或者一個樹形結構；

B、避免將一個請求的發送者與接收者耦合在一起

C、不純的職責鏈：一個具體處理者對象只能在兩個行為中選擇一個-要么承擔全部責

任，要么將責任推給下家；

D、職責鏈模式給對象職責的分配帶來更多的靈活性。

11、為了能成功地實施XP,XP制定的四個準則不包括：

A、文檔B、簡單C、反饋D、勇氣

12、關于用戶故事，下列說法正確的是：

A、用戶故事就是正在開發的項目的腳本；

B、是一個可行性分析工具；

C、用戶故事分解需求，一個用戶故事就是一個小的需求模塊；

D、“點數”能精確其實現代價。

13、關于代碼重構，下面的敘述錯誤的是

A、不斷修改的代碼往往會退化/腐化，導致難于維護，因此需要重構。

B、每個改造都是微不足道的，但是這些所有的改造迭加在一起，就形成了對系統設計和架

構顯著的改進。

C、每次重構進行完后，必須運行單元測試，保證重構沒有造成任何破壞，然后再去做下一

次重構。

D、重構是對代碼結構的全面優化，每次改動往往較大，耗費也較大，因此重構頻率不宜過

于頻繁。

14、關于工廠方法模式，下述觀點中不合適的是：

A、是創建型模式的一種B、核心的工廠類不負責創建對象

C、具體工廠類包含業務邏輯D、工廠類與產品類往往具有平行的等級結構

15、關于職責鏈模式，下列說法不正確的是：

A、職責鏈可以是一條直線、一個環或者一個樹形結構；

B、避免將一個請求的發送者與接收者耦合在一起

C、不純的職責鏈：一個具體處理者對象只能在兩個行為中選擇一個-要么承擔全部責任，要

么將責任推給下家；

D、職責鏈模式給對象職責的分配帶來更多的靈活性。

16、微軟推薦的三層架構不包括（）

A、業務邏輯層B、實體-聯系層C、數據訪問層D、表示層（界面層）

17、為了能成功地實施XP,XP制定的四個準則不包括：（）

A、文檔B、簡單C、反饋D、勇氣

18、在XP項目中，關于代碼重構，下面的敘述錯誤的是：（）

A、不斷修改的代碼往往會退化/腐化，導致難于維護，因此需要重構。

B、每個改造都是微不足道的，但是這些所有的改造迭加在一起，就形成了對系統設計

和架構顯著的改進。

C、每次重構進行完后，必須運行單元測試，保證重構沒有造成任何破壞，然后再去做

下一次重構。

D、重構是對代碼結構的全面優化，每次改動往往較大，耗費也較大，因此重構頻率不

宜過于頻繁。

19、關于單一職責原則，下述敘述錯誤的是：（）

A、就一個類而言，應該僅有一個引起它變化的原因。

B、過多職責耦合到一起后，一個職責的變化可能會削弱或者抑制這個類完成其他職責

的能力。

C、簡言之，就是加大類之間的耦合，減少類內部的內聚。

D、軟件設計真正要做的許多內容，就是發現職責并把那些職責互相分離.

20、關于替代原則，下述敘述錯誤的是：（）

A、只有父類能完全替代子類才能保證抽象父類的復用和擴展。

B、替代原則指導繼承，是繼承的基石。

C、對于LSP的違反常常會導致以明顯違反OCP。

D、繼承依賴的IS-A關系是就行為方式而言的。

21、關于依賴倒置原則，下述敘述錯誤的是：（）

A、高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象。

B、抽象不應該依賴于細節，細節應該依賴于抽象。

C、要針對接口編程，不要針對實現編程。

D、高層模塊實現了在低層模塊中聲明并被低層模塊調用的接口。

22、關于迪米特法則，下述說法中不恰當的是：（）

A、一個對象應當對其他對象有盡可能少的了解。

B、只與你“直接的朋友們”通信。

C、迪米特法則的核心觀念就是類間解耦。

D、應用符合迪米特法則后，類之間就是弱耦合，從而系統的不同模塊之間的通信效率

會相應的提高。

23、關于工廠方法模式，下述觀點中不合適的是：（）

A、是創建型模式的一種

B、核心的工廠類不負責創建對象

C、具體工廠類包含業務邏輯

D、工廠類與產品類往往具有平行的等級結構

24、關于原型模式，下述觀點不正確的是：（）

A、利用.Net中的McmberwiseClone（）可以實現淺表復制

B、利用序列化和反序列化不能實現深度復制

C、允許動態增加或減少產品類，增加新產品對整個結構沒有影響

D、擴展功能：可以帶有原型管理器

25、關于橋接模式，下述說法不正確的是：（）

A、將抽象部分與實現部分分離，使它們都可以獨立地變化

B、將一個事物中多個維度的變化分離

C、Implementor的接口必須與Abstraction的接口相同

D、使用“對象間的組合關系”解耦了抽象和實現之間固有的綁定關系

26、關于組合模式，下述說法不恰當的是：（）

A、組合模式中，數據之間的關系是典型的網狀結構

B、所有的節點可以采用一致的處理方法

C、安全的組合模式中，實際上違反了接口獨立原則

D、透明的組合模式，在實際執行過程中，存在隱患。

27、關于裝飾模式，下述說法不恰當的是：（）

A、動態地給一個對象增加一些額外的職責

B、比單純地使用繼承方式更為靈活

C、Decorator和Component的關系，首先是繼承關系，然后是組合關系

D、裝飾模式雖然產生的對象數量較少，但是會生成大量較小的類

28、關于模板方法模式，下述敘述不恰當的是：（）

A、定義一個操作中的算法的骨架，而將一些步驟的實現延遲到子類中。

B、強調使用組合替代繼承

C、將行為盡量移動到結構的高端

D、反向控制結構（IoC）是模版方法模式的典型應用

29、關于命令模式，下述說法不正確的是：（）

A、解決了“行為請求者”與“行為實現者”之間的緊耦合

B、將一些行為命令化，參數化

C、可以實現Undo和Redo

D、可能造成命令執行者對象過多是該模式的主要缺點

30、關于觀察者模式，下述說法不恰當的是：（）

A、解決的是對象間的一種多對多的依賴關系

B、既要保證對象間的低耦合，又能夠維持行動的協調一致，保證高度的協作

C、很好的體現了依賴倒置原則

D、在C#的實現方式中，委托定義可以充當抽象的Observer接口

二、判斷題

1.建造者模式要求復雜對象的各個部分經常面臨著劇烈的變化，但是將它們組合在一起的算法卻

相對穩定。（）

2.代理模式中，當代理對象將客戶端請求發送給真實對象之前或之后往往會添加一些額外的操作。

（）

3.在享元模式中，外部狀態可以共享，但是內部狀態不能共享。（）

4.外觀模式定義了一個高層接口，這個接口使得復雜子系統更加容易使用。（）

5.觀察者模式中，如果在被觀察者之間有循環依賴，可能導致“死鎖（）

6.軟件體系結構設計的一個核心問題是“復用"。（）

7.實體類實現所謂的對象關系映射（簡稱ORM）,是為了解決面向對象的類與關系數據庫的表之

間，存在的不匹配的現象。（）

8.合適的工具對成功來說是重要的，敏捷方法建議選用綜合功能比較全面的工具。（）

9.極限編程要求每2周發布一次軟件，稱為一次發布周期。（）

10.用戶故事的驗收測試是在就要實現該用戶故事之前或實現該用戶故事的同時進行編寫的。

（）

11.放置釣鉤（hook）以適應將來的軟件需求變化，是開放-封閉原則的典型應用。（）

12.繼承依賴的IS-A關系是就具體的行為方式而言的。（）

13.在設計類結構時，組合優于繼承。（）

14.設計模式描述了軟件設計過程中某一類常見問題的一般性的解決方案。（）

15.簡單工廠模式完全符合開放-封閉原則。（）

16.在VS中，一個Project可以包含多個Solution。（）

17.敏捷開發認為：完備的文檔是保證軟件系統質量的重要手段。（）

18.XP項目實施過程中，每個人應該分工明確，各自簽領自己擅長的任務。（）

19.在XP中，隱喻通常可以歸結為一個名字系統。（）

20.在敏捷開發中，設計和構架的過程是持續不斷的。（）

21.在代碼中放置“Hook”是開放/封閉原則實施的主要手段。（）

22.ISP原則認為，接口應該盡可能簡單，一個接口只做一件事情。（）

23.為減弱類間耦合，LoD提倡多使用序列化（Serialize）功能。（）

24.簡單工廠模式違反開放/封閉原則，而工廠方法模式符合開放/封閉原則，且完全不需要判

斷工廠的類型。（）

25.相比適配器模式，橋接模式實際上是個“事后諸葛亮”。（）

三、簡答題

1、簡述實體類的概念及其作用。

2、敏捷開發宣言。

3、簡述XP的短交付周期的概念。

4、測試驅動開發的概念及其積極作用。

5、XP中簡單設計的概念及其指導原則。

6、簡述常見的設計臭味。

7、簡述開放/封閉原則。

8、簡述什么是設計模式。

9、試給出抽象工廠模式的結構圖及其角色描述。

10、簡述觀察者模式的定義與結構。

1k軟件體系結構的概念及構成。

12、什么是結對編程？

13、測試驅動開發遵循的3條簡單的規則是什么？

14、簡述適配器模式的定義及對象適配器的結構。

15、簡述三層架構開發模式及其優點。

16、每個軟件模塊都應該具有的三項職責是什么？

17、為什么說“源代碼就是設計！”?

18、簡述單一職責原則。

19、簡述依賴倒置原則。

20、什么是面向對象的三大機制？

21、簡述簡單工廠模式的優缺點。

22、簡述XP中的完整團隊概念。

四、設計題

1、試給出多線程安全的“懶漢式”和“餓漢式”單件模式的代碼。

2、設計一個命令行狀態下運行的運算程序，目前支持加減乘除*,/）等四則運算，

將來還可能添加求余數（盼運算，請以學過的設計模式設計一個程序結構，先畫出類圖，再寫

出代碼。

要求：（1）符合開放/封閉原則：

（2）業務邏輯和界面邏輯必須分開；

（3）先設計只支持四則運算的程序，再說明如何升級程序加上求余數（％）運算。

3、銀行帳戶改動通知系統：帳戶的余額發生變化時，需要通過手機短信和E-Mail的方式

通知到用戶本人，試用所學過的設計模式實現該系統。

要求：（1）指出使用的設計模式的名稱；

（2）畫出該設計模式的類結構圖;

（3）給出系統模擬實現的代碼；

（4）設計符合開放/封閉原則。

4.最簡單的手機（SimplePhone）在接收到來電的時候，會發出聲音提醒主人，現在需要為

該手機添加一項功能，即在接收到來電的時候，除了有聲音還能產生震動（JarPhone）,還

可以得到更高級的手機(ComplexPhone),來電的時候，它不僅能夠發聲，產生震動，而

且有燈光閃爍提示。試用學過的設計模式實現該系統。

要求：給出設計模式的名稱及系統結構的類圖。

5、什么是開放封閉原則？簡要說明如何實現該原則。分別討論三種工廠模式(簡單工廠、

工廠方法和抽象工廠)在不使用反射技術時，是否支持開放封閉原則。

6、在某系統的圖表處理模塊中，需要將圖表(Chart)顯示和圖表數據采集

(DataCollection)分離，系統可支持多種圖表(如柱狀圖BarChart,餅狀圖PieChart等)，

也提供了多種數據采集方式，例如可以從文本文件中讀取數據(TxtDataCollection),也可

以從數據庫中讀取數據(DBDataCoIlection),還可以從Excel文件中獲取數據

(ExcelDataCollection),如果需要從Excel文件中獲取數據，則需要調用與Excel相關的

APL例如讀取Excel文件的ExcelReader類，而這個API是現有系統所不具備的。試用學

過的2種設計模式來實現該系統。

要求：給出設計模式的名稱及系統結構的類圖。

一、選擇題

CDABCDABCCACDCCBADCADDCBCADBDA

二、判斷題

VVXVVVVxXVXVVVxXXXXVVXVXXX

三、簡答題

1、簡述實體類的概念及其作用。

實體類實現所謂的對象關系映射(ObjectRelationalMapping,簡稱ORM),是

為了解決面向對象的類與關系數據庫的表之間，存在的不匹配的現象，通過使

用描述對象和關系之間映射的元數據，在程序中的類對象，與關系數據庫的表

之間建立持久的關系，用于在程序中描述數據庫表。本質上就是將數據從一種

形式轉換到另外一種形式。

簡單地說，就是描述一個業務實體的類。實體類對象是現實世界中實體對象在

計算機中的表示，在層與層之間以及層內模塊間進行數據傳輸。

2、敏捷開發宣言。

我們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發方法，通過這

項工作，我們認為：

個體和交互勝過過程和工具

可以工作的軟件勝過面面俱到的文檔

客戶合作勝過合同談判

響應變化勝過遵循計劃

雖然右項也有其價值，但我們認為左項更加重要。

3、簡述XP的短交付周期的概念。

迭代計戈U：XP項目每兩周交付一次可以工作的軟件。每兩周的迭代都實現了利

益相關者的一些需求，在每次迭代結束時，會給利益相關者演示迭代生成的系

統，以得到他們的反饋。迭代是一次較小的交付，可能會被加入到產品中，也

可能不會。每個周期(Iteration)開發的需求都是用戶最需要的東西。

發布計劃：XP團隊通常會創建一個計劃來規劃隨后大約6次迭代的內容。一次

發布通常需要2-3個月的工作。它表示了一次較大的交付，通常此次交付會被

加入到產品中。發布計劃不是一成不變的，客戶可以隨時改變計劃的內容，他

可以取消用戶故事，編寫新的用戶故事，或者改變用戶故事的優先級別。但是

客戶應該更改后面迭代的內容，盡量不要更改下一次迭代。

4、測試驅動開發的概念及其積極作用。

編寫所有產品代碼的目的都是為了使失敗的單元測試能夠通過。首先編寫一個

單元測試，由于它要測試的功能還不存在，因此它會運行失敗，然后，編寫代

碼使測試通過。編寫測試用例和代碼之間的更迭速度是很快的，基本上在幾分

鐘左右。

積極的影響：

(1)程序中的每一項功能都有測試來驗證它的操作的正確性。

(2)首先編寫測試可以迫使我們使用不同的觀察點一程序調用者的角度，

可以設計出便于調用的軟件

(3)通過首先編寫測試，可以迫使自己把程序設計為可測試的，迫使我們

解除軟件中的耦合(forceustodecouplethesoftware)

(4)測試可以作為一種無價的文檔形式，而且可以提供范例

5、XP中簡單設計的概念及其指導原則。

XP團隊使他們的設計盡可能地簡單、具有表現力(expressive)。此外，他們僅

僅關注于計劃在本次迭代中要完成的用戶故事。他們不會考慮那些未來的用戶

故事。

XP要求用最簡單的辦法實現每個小需求，前提是按照這些簡單設計開發出

來的軟件必須通過測試。這些設計只要能滿足系統和客戶在當下的需求就可以

了，不需要任何畫蛇添足的設計，而且所有這些設計都將在后續的開發過程中

被不斷地重整和優化。

3條XP指導原則：

(1)考慮能工作的最簡單的事情

盡量考慮最簡單的方法實現當前的用戶故事。

(2)你不需要它

將來會用到，現在不考慮，不得不用時再添加；

(3)一次，并且只有一次

極限編程者絕不能容忍重復的代碼

6、簡述常見的設計臭味。

僵化性是指難以對軟件進行改動，即使簡單的改動；脆弱性是指，在進行一個

改動時，程序的許多地方就可能出現問題；牢固性是指，設計中包含了對其他

系統有用的部分，但是要把這些部分從系統中分離出來所需要的努力和風險是

巨大的；軟件的粘滯性和環境的粘滯性：當那些可以保持系統設計的方法比那

些拼湊手法更難應用的時候，就表明設計具有高的粘滯性，當開發環境遲鈍、

低效時，就會產生環境的粘滯性；如果設計中包含有當前沒有用的組成部分，

它就包含不必要的復雜性；不必要的重復，剪切和粘貼也許是有用的文本編輯

操作，但是它們卻是災難性的代碼編輯操作；晦澀性是指模塊難以理解。

7、簡述開放/封閉原則。

開放-封閉原則：軟件實體(類、模塊、函數等)應該是可以擴展的，但是不可

修改。

(1)對于擴展是開放的-這意味著模塊的行為是可擴展的。我們可以根據需求

的變化來改變模塊的功能

(2)對于修改是封閉的-對模塊行為進行擴展時，不必改動模塊的源代碼或二

進制代碼(需要重新編譯即為修改)

把一個功能的通用部分和實現細節清晰的分離開來；通過派生來擴展功能。

8、簡述什么是設計模式。

每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的解決方

案的核心。

設計模式描述了軟件設計過程中某一類常見問題的一般性的解決方案。-經驗

性的好的方案

面向對象設計模式描述了面向對象設計過程中、特定場景下、類與相互通信的

對象之間常見的組織關系。

9、試給出抽象工廠模式的結構圖及其角色描述。

所謂的抽象工廠是指一個工廠等級結構

可以創建出分屬于不同產品等級結構的

一個產品族中的所有對象。

抽象工廠(AbstractFactory)角色:擔

任這個角色的是工廠方法模式的核心，

它是與應用系統商業邏輯無關的(給出

創建對象的幾個方法的說明)。

具體工廠(ConcreteFactory)角色：這

個角色直接在客戶端的調用下創建多個

具體產品的實例。這個角色含有選擇合

適的產品對象的邏輯，而這個邏輯是與

應用系統的商業邏輯緊密相關的(實現

具體的創建方法)。

抽象產品(AbstractProduct)角色：擔

任這個角色的類是工廠方法模式所創建

的具體對象的父類，或它們共同擁有的

接口一給出產品對象業務上的共同點。

具體產品(ConcreteProduct)角色：抽象工廠模式所創建的任何產品對象都是

某一個具體產品類的實例。這是客戶端最終需要的東西，其內部一定充滿了應

用系統的商業邏輯。

10、簡述觀察者模式的

結構。

定義對象間的一種一對

多的依賴關系，以便當

一個對象的狀態發生改

變時，所有依賴于它的

對象都得到通知并自動

更新。

抽象主題(Subject)角

色：抽象主題角色把所

有對觀察考對象的引用

保存在一個聚集里，每

個主題都可以有任何數

量的觀察者。抽象主題

提供一個接口，可以增

加和刪除觀察者對象，

主題角色又叫做抽象被觀察者(Observable)角色，一般用一個抽象類或者一個

接口實現。

抽象觀察者(Observer)角色：為所有的具體觀察者定義一個接口，在得到主

題的通知時更新自己。這個接口叫做更新接口。抽象觀察者角色一般用一個抽

象類或者一個接口實現。在這個示意性的實現中，更新接口只包含一個方法

(即Update。方法)，這個方法叫做更新方法。

具體主題(ConcreteSubject)角色：將有關狀態存入具體現察者對象；在具體

主題的內部狀態改變時，給所有登記過的觀察者發出通知。具體主題角色又叫

做具體被觀察者角色(ConcreteObservable)。具體主題角色通常用一個具體子

類實現。

具體觀察者(ConcreteObserver)角色：存儲與主題的狀態自恰的狀態。具體現

察者角色實現抽象觀察者角色所要求的更新接口，以便使本身的狀態與主題的

狀態相協調。如果需要，具體現察者角色可以保存一個指向具體主題對象的引

用。具體觀察者角色通常用一個具體子類實現。

11、軟件體系結構的概念及構成。

答案：軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理

構件、數據構件和連接構件。處理構件負責對數據進行加工；數據構件是被加

工的信息；連接構件把體系結構的不同部分組合連接起來。

12、什么是結對編程？

答案：所有產品(production)代碼都是由結對的程序員使用同一臺電腦共同完

成的，結對人員中的一位控制鍵盤并輸入代碼，另一位觀察輸入的代碼并尋找

著代碼中的錯誤和可以改進的地方。兩人頻繁互換角色，結對的關系每天至少

改變一次，以便于每個程序員在一天中可以在兩個不同的結對中工作，“業務

領域專家”也需要與團隊中的其他所有成員結對。

13、測試驅動開發遵循的3條簡單的規則是什么？

答案：除非已經編寫了一個不能通過的單元測試，否則不編寫任何產品代碼；

只要編寫能夠正好導致測試不通過或者編譯失敗的單元測試就夠了，無需再

多；

只要編寫能夠正好使失敗的單元測試通過的產品代碼就夠了，無需再多。

遵循上述原則，以非常短的周期（1-2分鐘）迭代；

14、簡述適配器模式的定義及對象適配器的結構。

答案：將一個類的接口轉換成客戶希望的另一個接口。Adapter模式使得原本由

于接口不兼容而不能一起工作的那些類可以一起工作。

15、簡述三層架構開發模式及其優點。

微軟推薦的三層結構通常是指數據訪問層（DAL）、業務邏輯層（BLL）和表示

層（UI）o

與網絡協議的分層一樣，軟件設計也要進行分層，分層的目的是為了實現“高

內聚、低耦合”，采用“分而治之”的思想，把任務劃分成子任務，逐個解決，

易于控制，易于延展，易于多人進行項目合作。

優點：

不必為了業務邏輯上的微小變化而導至整個程序的修改，只需要修改商業邏輯

層中的一個函數或一個過程一靈活，適應多變的需求；增強了代碼的可重用

性；便于不同層次的開發人員之間的合作，只要遵循一定的接口標準就可以進

行并行開發了，最終只要將各個部分拼接到一起構成最終的應用程序。

16、每個軟件模塊都應該具有的三項職責是什么？

它運行起來所完成的功能，這也是該模塊得以完成的原因。

它要應對變化，幾乎所有的模塊在它們的生命周期中都要變化。開發者有責任

保證這種改變應該盡可能地簡單。

它要和閱讀它的人進行溝通。對該模塊不熟悉的開發人員應該能夠比較容易地

閱讀并理解它。

17、為什么說“源代碼就是設計!”？

軟件項目的設計是一個抽象的概念，它和程序的概觀、結構以及每一個模塊、

類和方法的詳情和結構有關，可以使用許多不同的媒介描繪設計，但是最終的

體現為源代碼。

Reeves認為：

軟件系統的源代碼是它的主要設計文檔。

用來描繪源代碼的圖示只是設計的附屬物而不是設計本身。

從根本上講，源代碼就是設計！

18、簡述單一職責原則。

就一個類而言，應該僅有一個引起它變化的原因。

在SRP中，我們把職責定義為“變化的原因"(areasonforchange)0

軟件設計真正要做的許多內容，就是發現職責并把那些職責互相分離(找到變化

點,并封裝之)。事實上，我們將要論述的其余原則都會以這樣或那樣的方式回到

這個問題上。

19、簡述依賴倒置原則。

高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象。

抽象不應該依賴于細節，細節應該依賴于抽象。

要針對接口編程，不要針對實現編程。

20、什么是面向對象的三大機制？

各種面向對象編程語言相互有別，但都能看到它們對面向對象三大機制的支

持，即：“封裝、繼承、多態”

封裝，隱藏內部實現

繼承，復用現有代碼，擴展已有的行為

多態，改寫已有的行為

21、簡述簡單工廠模式的優缺點。

優點：

工廠類含有必要的判斷邏輯，可以決定在什么時候創建哪一個產品類的實例，

客戶端可以免除直接創建產品對象的責任，而僅僅"消費"產品。簡單工廠模式

通過這種做法實現了對責任的分割。

缺點：

當產品有復雜的多層等級結構時，工廠類只有自己，以不變應萬變，就是模式

的缺點。因為工廠類集中了所有產品創建邏輯，一旦不能正常工作，整個系統

都要受到影響。

違反開放/封閉原則：系統擴展困難，一旦添加新產品就不得不修改工廠邏輯，

有可能造成工廠邏輯過于復雜。

另外，簡單工廠模式通常使用靜態工廠方法，這使得無法由子類繼承，造成工

廠角色無法形成基于繼承的等級結構。

22.簡述XP中的完整團隊概念。

答案:客戶、管理者和開發人員應該緊密地工作在一起，以便彼此知曉對方所面

臨的問題，并共同去解決這些問題。XP團隊中的客戶是指定義產品的特性并排

列這些特性優先級的人或者團體。最好的情況是客戶和開發人員在同一個房間

中工作，次一點的情況是客戶和開發人員之間的距離在100米內。如果確實無

法和客戶在一起工作，那么就去尋找能夠在一起工作、愿意并能夠代替真正客

戶的人。

四、設計題

1、試給出多線程安全的“懶漢式”和“餓漢式”單件模式的代碼。

publicclassSingleton〃懶漢式

(

〃唯一的實例對象,每次訪問時重新讀取instance變量的值

privatestaticvolatileSingletoninstance=null;

privatestaticreadonlyobjectlockHelper=newobject。;“輔助加鎖對象

privateSingleton。〃私有構造函數，防止外部應用使用new方法創建新

的實例

publicstaticSingletonGetlnstance。//獲取唯一的實例對象

{

if(instance==null)//先判斷對象是否存在-這樣做能夠保證執行效

率！

(

lock(lockHelper)//加鎖--創建臨界區

(

if(instance==null)//加鎖后二次判斷，只允許一個線程

判斷

instance=newSingleton();

returninstance;

publicclassSingleton〃餓漢式

{

//公共靜態只讀屬性-依靠系統在加載時進行初始化，對于多線程環境

也是安全的

publicstaticreadonlySingletoninstance=newSingleton();

privateSingleton()〃私有構造函數，防止外部應用使用new方法創建

新的實例

()

2、設計一個命令行狀態下運行的運算程序，目前支持加減乘除*,/)

等四則運算，將來還可能添加求余數(％)運算，請以學過的設計模式設計一個

程序結構，先畫出類圖,再寫出代碼。

要求：(1)符合開放/封閉原則；

(2)業務邏輯和界面邏輯必須分開；

(3)先設計只支持四則運算的程序，再說明如何升級程序加上求余數

(%)運算。

類圖:

代碼：

Operation.es:

///<summary>

///抽象的運算基類

///</summary>

publicclassOperation

(

〃二個運算對象

privatedouble_nuiTiberA;

privatedouble_numberB;

///<summary>

///運算數A

///</summary>

publicdoubleNumberA

(

get{return_numberA;}

set{_numberA=value;}

)

III<summary>

III運算數B

III</summary>

publicdoubleNumberB

get{return_numberB;}

set{_numberB=value;}

)

〃獲取運算結果，此處為虛方法，子類必須重寫

publicvirtualdoubleGetResult()

(

doubleresult=0;

returnresult;

)

)

OperationAdd.es:

///<summary>

〃/加法類，派生自運算類，在GetResult方法中具體實現加法運算

III</summary>

publicclassOperationAdd:Operation

(

publicoverridedoubleGetResult。//實現具體的加法運算

(

doubleresult=0;

result=NumberA+NumberB;

returnresult;

)

)

與上面的OperationAdd類似有OperationSub>OperationMuI和OperationDiv

OperationFactory.es：

///<summary>

///運算對象工廠類

///</summary>

publicclassOperationFactory

(

publicstaticOperationCreateOperate(stringoperate)〃根據傳進來的運算

符來決定創建什么樣的對象

(

return(Operation)Assembly.Load("程序集名稱”).Createlnstance(轉

換運算符為類名稱(operate));

)

主程序：

classProgram

{

staticvoidMain(string[]args)

〃輸入運算對象和運算符

Console.Write。請輸入數字A：n);

stringstrNumberA=Console.ReadLine();

Console.Write(”請輸入運算符*,/,%)：n);

stringstrOperate=Console.ReadLine();

Console.Write("請輸入數字B：n);

stringstrNumberB=Console.ReadLine();

〃由工廠創建運算對象

Operationoperate=OperationFactory.CreateOperate(strOperate);

〃設置要運算的數據

operate.NumberA=Convert.ToDouble(strNumberA);

operate.NumberB=Convert.ToDouble(strNumberB);

〃具體作運算-動態決定調用哪個子類的GetResult()方法

doubleresult=operate.GetResult();

〃顯示運算結果

Console.WriteLine(strNumberA+strOperate+strNumberB+”=

+result);

Console.ReadLine();

)

catch(Exceptionex)

Console.WriteLine("您輸入的數據有錯誤!n+ex.ToStringO);

Console.ReadLine();

擴展程序功能：

仿照前面的OperationAdd添加支持新運算的類OperationMod,對運算符(％)

轉換為類名OperationMod作設置改變，重新編譯系統即可。

3、銀行帳戶改動通知系統：帳戶的余額發生變化時，需要通過手機短信和E-

Mail的方式通知到用戶本人，試用所學過的設計模式實現該系統。

要求：(1)指出使用的設計模式的名稱;

(2)畫出該設計模式的類結構圖;

(3)給出系統模擬實現的代碼；

(4)設計符合開放/封閉原則。

答案：

使用觀察者模式。

代碼：

///<summary>

///Observer一抽象觀察者接口

///</summary>

publicinterfaceAccountUpdated

///<summary>

///觀察者接收/處理通知的方法

///</summary>

///<paramname="val">帳戶余額</param>

voidBalanceUpdated(doubleval)；

)

///<summary>

///具體觀察者一帳戶余額發生變化時，發送Email通知用戶

///</summary>

classEmai1：AccountUpdated

!

///<summary>

///接收郵件通知的E-Mail地址

///</summary>

privatestringEmailAddress；

publicEmail(stringaddress)

|

EmailAddress=address；

)

///<summary>

///發送Email通知操作

///</summary>

///<paramname=余額數值</param>

publicvoidBalanceUpdated(doubleval)

Console.WriteLine("發送郵件到{0},余額為{1}.M,

EmailAddress,val)；

}

〃其他操作相關的屬性和方法

)

///<summary>

///具體觀察者一帳戶余額發生變化時，通過手機發送短信通知用戶

///</summary>

classMobile：AccountUpdated

(

///<summary>

///接收短信通知的電話號碼

///</summary>

privatestringPhoneNumber；

publicMobile(stringphone)

(

PhoneNumber=phone；

)

///<summary>

///發送短信通知

///</summary>

///<paramname="val">余額數值</param>

publicvoidBalanceUpdated(doubleval)

ConsoleWriteLine("發送短信至手機{0},余額為{1}.

PhoneNumber,val)；

)

〃其他操作相關的屬性和方法

)

///<summary>

///ConcreteSubject具體主題--銀行帳戶

///</summary>

classBankAccount：Subject

(

///<summary>

///帳戶余額--subjectState

///</summary>

privatedoublebalance=0；

///<summary>