前言 大家好，我是老馬。很高興遇到你。 我們為 java 開發者實現了 java 版本的 nginx https://github.com/houbb/nginx4j 如果你想知道 servlet 如何處理的，可以參考我的另一個項目： 手寫從零實現簡易版 tomcat minicat 手寫 ngin ...
OO第二次blog作業
前言
這三次的作業可以分為兩個階段，前一個階段是上三次作業“答題判題程式”的進一步迭代，而後一部分則是另一道題目“家居強電電路模擬程式”。
從結果來看，電路模擬程式的完成不盡人意，尤其是第二次迭代的電路模擬，由於這次沒有了測試點的提示，導致程式在提交出現錯誤後不知從何處下手進行修改。這也是個慘痛的教訓，在真正的現實情況下，肯定是不會有測試點提示的。日後要爭取在設計階段進行優化，提前考慮好可能出現的各種情況，彌補這次的失誤。
後續將對近三次作業進行一些具體的分析。
三次作業分析
第一次作業
第一次作業是對上次答題判題程式的進一步迭代。在此次迭代中，題目加入了多選題和填空題的類型，並且輸入順序方面也進行了改動。只要是正確類型的數據便可以任意順序輸入。除此之外還引入了多張試卷的情況，按照學生學號和試卷號對輸出進行排序。
由於引入了兩種新的題目類型，採用繼承的方法來定義三種不同的題目類。
Stone類作為題庫，其中存儲一個鏈表，包含所有輸入題目的信息。後續刪除的行為也是對此處進行操作。
Respond類、Paper類和Student類分別用於存儲答卷、試卷和學生信息。
GetMassage類用於對輸入的信息進行判別、處理以及相應的存儲。
Judge類作為代理類，用於對學生的答卷進行判斷並輸出相應的數據。
SourceMonitor分析結果如下
![image]
由於在是上一次的代碼上進行了改進，在修正了一些錯誤的同時也延續了代碼的一些問題，比如採用多重分支語句等，導致代碼的深度和複雜度仍舊居高不下。
第二次作業
第二次作業出現了新的題型——“家居強電電路模擬程式”，這次的題型模擬包括了三種控制設備和三種受控設備。
由於是第一次迭代，模擬情況僅包含了單條串聯電路。
定義了兩個父類控制類和用電器類，三種控制設備類受控設備類分別繼承自這兩個父類。
還定義了一個Ponit類啊作為代理類，用於輸入信息、對輸入信息進行處理和輸出信息。
SourceMonitor分析結果如下
從圖中可以看出，代碼的深度和平均複雜度較低，但最大複雜度過高，這是由於在Point類中當處理輸入信息時使用了多重分支語句和多重迴圈所導致的。
第三次作業
第三次作業是前一次作業的迭代，在這次作業中，加入了並聯電路的情況和一種新的用電器落地扇。
這次作業的難度無疑是又上了一個臺階，不僅僅是設計的難度提高了，而且沒有給出測試點也是給我們出了一個難題。
由於上一次的代碼難以對並聯電路的輸入進行處理，因此本次迭代對代碼進行了重構。
相較於上次代碼，本次代碼構建了Skewer類和Combine類分別為串聯電路類和並聯電路類。
此次代碼還構建了一個最高級父類Machine類，並聯電路類、控制類和用電器類都繼承自這個類。Machine類的構建使得我能夠在定義串聯電路類時使用一個鏈表來存儲信息。
SourceMonitor分析結果如下
從圖中可以看出，經過本次代碼的重構，代碼的複雜度有了顯著的下降，這主要是由於定義了串聯電路類與並聯電路類的原因。並且Machine類的使用使得在串聯電路中對數據的調用和計算複雜度更低。
下麵進行對三次作業的歷程進行一些詳細的描述與心得分享。
歷程
第一次作業
這是在本次代碼修改後的第一次提交，本次提交修改了信息的輸入和處理，實現了信息的亂序輸入，但對於多份答卷的問題還未得到解決。同時本份代碼也存在其他問題，會使得出現分零返回的情況。
此次修改更正了信息的調用部分，解決了數組越界所引起的非零返回問題。但是對於多張試卷的問問題仍未得到解決。
在試卷類中加入了用於處理多張試卷的屬性後，多張試卷的問題得到瞭解決，但仍有少數測試點存在問題。但在後續修改了某些會出現問題的情況後也得到瞭解決。
第二次作業
這是本次代碼的首次提交情況，由於但由於分檔調節器的部分問題導致有些測試點出現錯誤，在修正後便解決。
在與同學的交流中，我得知了最後三個測試點的情況是在用電器的兩端都有一個開關，但由於我本次代碼的設計問題，它只能處理一個控制元件和一個用電器的情況，所以導致沒有通過這三個測試點。這個問題直到下一次大作業中才得到解決。
第三次作業
在我看來這次作業相較於上次的難度提高了不少，在首次提交時我只拿到了三分，並且還出現了非零返回的情況。在對代碼的檢查後發現時在對串聯電路信息進行存儲後在調用時沒有及時更新導致調用的數據錯誤或是不存在在導致的。
在對信息輸入進行了少許的修改後，又多過了幾個測試點，並且也解決了非零返回的問題。
對計算設備數據時如何調用串聯電路資料庫中的數據部分進行修改，又正確了一部分，但由於沒有測試點的提示，導致不知道下一步應該對何處進行優化。
總結
在設計方面還需具有前瞻性，要考慮到對後續功能添加的情況，否則每次對代碼進行迭代時都需要進大量的重構，耗費大量的時間不說，還可能會出現很多bug。
此外，最後一次作業沒有給出測試點，因此導致自己不知從何處進行下一步的優化。然而在現實案例中，是不可能像這樣給出一個個測試點的。因此，自身尋找錯誤的能力也需要加強。
