20個設計模式和軟件設計面試問題

jopen 10年前發布 | 30K 次閱讀設計模式

不管是參加Java面試還是C#面試，設計模式和軟件設計都是任何編程面試中的必問問題。實際上，編程能力和設計技巧是對彼此很好的補充。一個好的程序員通常都是一個好的軟件設計人員。他們知道怎么把一個問題分割成一段段代碼或者軟件設計，但這些能力和技巧并不能憑空而來。你需要持續做大型、小型系統的設計和編碼，并且不斷從錯誤中學習。從面向對象設計原則開始是一個不錯的選擇。好吧，這篇文章是關于一些在各種面試中頻繁問到的一些設計問題。考慮到針對性和困難度，我把它們分成兩個種類，分別針對初學者和有經驗的人。

對中高級別的設計模式面試問題

這是一些和設計模式還有軟件設計都相關的問題。這些問題需要一些思考和經驗來回答。在大多數情況下，面試官并不是需要一個確切的答案，而是希望聽到你的想法，你對這個問題是怎么考慮的，你能不能想通這個問題，能不能挖掘一些沒有告訴你的潛在信息。在解決一個問題時你應該考慮什么等等可以使你經驗大漲。總的來說，這些設計問題會讓你動起腦來。有時面試官也會讓你寫代碼，所以還是準備一下吧。如果你知道編程和設計技巧中的概念，例子和程序，你應該可以在這些問題中有突出的表現。

1. 舉出一個例子，在這種情況你會更傾向于使用抽象類，而不是接口？

這是很常用但又是很難回答的設計面試問題。接口和抽象類都遵循”面向接口而不是實現編碼”設計原則，它可以增加代碼的靈活性，可以適應不斷變化的需求。下面有幾個點可以幫助你回答這個問題：

在Java中，你只能繼承一個類，但可以實現多個接口。所以一旦你繼承了一個類，你就失去了繼承其他類的機會了。

接口通常被用來表示附屬描述或行為如：Runnable、Clonable、Serializable等等，因此當你使用抽象類來表示行為時，你的類就不能同時是Runnable和Clonable(譯者注：這里的意思是指如果把Runnable等實現為抽象類的情況)，因為在Java中你不能繼承兩個類，但當你使用接口時，你的類就可以同時擁有多個不同的行為。

在一些對時間要求比較高的應用中，傾向于使用抽象類，它會比接口稍快一點。

如果希望把一系列行為都規范在類繼承層次內，并且可以更好地在同一個地方進行編碼，那么抽象類是一個更好的選擇。有時，接口和抽象類可以一起使用，接口中定義函數，而在抽象類中定義默認的實現。

希望了解更多關于Java接口的，可以看我的文章Java接口需要知道的10件事。

2. 設計一個販賣機，可以接收不同的貨幣，出售不同的產品？

這是一個開放設計問題，你可以作為練習，嘗試著寫出設計文檔、代碼和JUnit測試而不是只是解決這個問題，看看它花了你多少時間得到解決方案和得到需要的原形。理想情況下，這個問題應該可以在3個小時內解決，至少應該得到一個可以運行的版本。

3. 你有一個Smartphone類，可以派生如IPhone、AndroidPhone、WindowsMobilePhone類

它還可以是一些有著品牌的手機名稱，你會怎么設計這個類系統呢。

這是另外一個設計模式練習，你可以應用你的面向對象設計技巧來得到一個設計，這個設計需要足夠靈活能夠支持未來產品的擴展，足夠穩定能夠支持在現有模型進行修改。

4. 在Java中，什么時候用重載，什么時候用重寫？

對有經驗的Java設計師來說，這是一個相當簡單的問題。如果你看到一個類的不同實現有著不同的方式來做同一件事，那么就應該用重寫（overriding），而重載（overloading）是用不同的輸入做同一件事。在Java中，重載的方法簽名不同，而重寫并不是。

5. 設計一個ATM機？

我們所有人都使用ATM(自動柜員機)。想想你會怎么設計一個ATM？就設計金融系統來說，必須知道它們應該在任何情況下都能夠如期工作。不管是斷電還是其他情況，ATM應該保持 正確的狀態（事務） , 想想 加鎖（locking）、事務（transaction）、錯誤條件（error condition）、邊界條件（boundary condition） 等等。盡管你不能想到具體的設計，但如果你可以指出非功能性需求，提出一些問題，想到關于邊界條件，這些都會是很好的一步。

6. 你正在寫一些類提供市場數據，你知道你可以不定時切換不同的廠商如Reuters、wombat或者直接的批發商，你會如何設計你的市場數據系統。

這是一個非常有趣的設計面試問題，并且真的在一家大的投資銀行問到過，如果你是用Java編碼的話這是一個相當平常的場景。最主要的一點是你要有一個MarketData接口，它會有調用端需要的方法如：getBid()、getPrice()、getLevel()等等，而MarketData應該由一個MarketDataProvider通過 依賴注入（dependency injection） 組成。因此，當你修改你的MarketData 提供器（MarketDataProvider）時，調用端不會受影響，因為它們是通過MarketData接口或類的方法來訪問的。

7. 在Java中，為什么不允許從靜態方法中訪問非靜態變量？

你在Java中不能從靜態上下文訪問非靜態數據只是因為非靜態變量是跟具體的對象實例關聯的，而靜態的卻沒有和任何實例關聯。你可以看我的文章為什么在靜態上下文中不能訪問非靜態變量查看詳細的討論。

8. 在Java中設計一個并發規則的pipeline？

并發編程或并發設計這些天很火，它可以充分利用現在不斷提升的高級處理器的處理能力，而Java成為一個多線程語言也從這種情況獲益良多。設計一個并發系統需要記住的最關鍵的點是線程安全，不可變性，本地變量和避免使用static或者類變量（instance variables）。你只需要想著每一類都可以同時被多個線程同時執行，所以最好的做法就是每一個線程都處理自己的數據，不跟其他數據交互，并且運行時只需要最小的同步保證。這個問題可以涉及到從最初的討論到完整的類和接口編碼，但只要你記住并發中最重要的點和問題如，競爭條件（race condition）、死鎖（deadlock）、內存交互問題（memory interference）、原子性、ThreadLocal變量等，你都可以回答它。

給初學者的設計模式面試問題

這些軟件設計和設計模式問題大多在初學者層次時被問起，目的只是了解一下候選人(應聘者)對設計模式知道多少，如， 設計模式是什么 或者 一個特定的設計模式做什么 ?這些問題通過簡單地記憶概念就可以回答，但就信息和知識而言還是有價值的。

1. 什么是設計模式？你是否在你的代碼里面使用過任何設計模式？

設計模式是世界上各種各樣程序員用來解決特定設計問題的嘗試和測試的方法。設計模式是代碼可用性的延伸。

2. 你可以說出幾個在JDK庫中使用的設計模式嗎？

裝飾器設計模式（Decorator design pattern）被用于多個Java IO類中。單例模式（Singleton pattern）用于Runtime，Calendar和其他的一些類中。工廠模式（Factory pattern）被用于各種不可變的類如Boolean，像Boolean.valueOf，觀察者模式（Observer pattern）被用于Swing和很多的事件監聽中。

3. Java中什么是單例設計模式？用Java寫出線程安全的單例

單例模式重點在于在整個系統上共享一些創建時較耗資源的對象。整個應用中只維護一個特定類實例，它被所有組件共同使用。Java.lang.Runtime是單例模式的經典例子。你可以在我的文章Java單例模式的10個問題看到更多的問題和討論。從Java 5開始你可以使用枚舉（enum）來實現線程安全的單例。

4. 使用工廠模式最主要的好處是什么？你在哪里使用？

工廠模式的最大好處是增加了創建對象時的封裝層次。如果你使用工廠來創建對象，之后你可以使用更高級和更高性能的實現來替換原始的產品實現或類，這不需要在調用層做任何修改。可以看我的文章工廠模式得更詳細的解釋和和了解更多的好處。

5. 在Java中，什么叫觀察者設計模式（observer design pattern）？

觀察者模式是基于對象的狀態變化和觀察者的通訊，以便他們作出相應的操作。簡單的例子就是一個天氣系統，當天氣變化時必須在展示給公眾的視圖中進行反映。這個視圖對象是一個主體，而不同的視圖是觀察者。可以在這篇文章中看到Java觀察者模式的完整例子。

6. 舉一個用Java實現的裝飾模式(decorator design pattern)？它是作用于對象層次還是類層次？

裝飾模式增加強了單個對象的能力。Java IO到處都使用了裝飾模式，經典的例子就是Buffered系列類如BufferedReader和BufferedWriter，它們增強了Reader和Writer對象，以實現提升性能的Buffer層次的讀取和寫入。可以看這篇文章了解更多。

7. 什么是MVC設計模式？舉一個MVC設計模式的例子？

8, Java中什么是表示層設計模式（FrontController design pattern）？舉一個使用表示層設計模式（front controller pattern）的例子？

9. 什么是責任鏈模式（Chain of Responsibility）？

10. 什么是適配器模式？舉用Java實現適配器模式的例子？

這些留給你自己做練習，作為面試準備，試著去找出這些設計模式的答案。

這些是我在很多面試中都看到的設計模式問題，當然，在google面試和各種各樣的公司如Amzone、Microsoft等等還有很多重要的專業軟件設計問題。如果你遇到一些有趣的值得分享的設計問題，不妨分享出來。