7.4 違背設計模式實現

按照通常的需求迭代過程，往往最開始都是非常簡單的，也是非常容易實現的。需求最初的模樣，只是給每位考生創建出一張試卷即可，對于這樣簡單的需求，如果不仔細思考，可能會把所有代碼寫到一個類里。

7.4.1 工程結構

這個工程的結構只有一個用于生成試卷的控制類QuestionBankController，接下來看這樣的類是如何實現的。

7.4.2 所有需求都寫到一個類里

以上的代碼主要包括三部分內容：將選擇題和問答題創建到集合中，定義詳情字符串包裝結果，返回結果內容。單從代碼閱讀角度來看，這樣的代碼并不復雜，且更易于理解。因為它的編程方式不面向對象，只面向程序過程，業務邏輯需要什么就直接寫什么。不考慮擴展性，能運行即可。但這段代碼沒有實現題目和答案亂序的功能，最終所有人的試卷題目的順序都是一樣的。如果需要增加混排題目功能，則代碼實現就會非常混亂。

7.4.3 測試驗證

1.單元測試

在單元測試中，調用了三次創建試卷的方法questionBankController.createPaper，給三位考生創建了三張試卷。

2.測試結果

以上是花花、豆豆和大寶三位考生的試卷：每個人的試卷內容是一樣的，三個人的題目及答案順序也一樣，沒有達到混排的要求。而且以上這樣的代碼很難擴展，隨著題目的不斷增加及亂序功能的補充，都會讓這段代碼變得越來越混亂。另外，這三張試卷本身題目一致，但在程序的實現方面，每次都需要創建題目信息，這相當于反復從數據庫或者遠程RPC接口中獲取數據，會浪費服務資源。