面向對象課程總結
一、單元4架構設計
作業1
作業1，我在頂層采用了HashMap將類（接口）與其對應的内容進行一一映射存儲，進而將查詢操作向下分配給ClassDetails。在對類內方法的參數的存儲上，我采取了相似的方法，即使用OperationDetails類存儲，并將對方法參數類型的查詢分配到該類內部。這是一系列可以用HashMap層層向下找的過程。
我還設計了一個單例類AllElements，這個類用來存儲所有的id與UmlElement的映射關係，這使得程序從任何一個地方都可以根據id得到對應的UmlElement。此外爲了方便，我還設計了一個單例類AllMaps，方便在ClassDetails類內部進行DFS操作時可以根據UmlClass或UmlInterface取得對應的Details。
作業2
作業2中，由於是對作業1進行擴展，即添加了新類型的Uml圖，因此我將不同類型的圖放到三個不同的package中，分別對三個圖進行處理。當調用到對應圖的方法時，由MyUmlGeneralInteraction類對下層的三個Interaction類方法進行調用。
這裏沿用作業1的設計。
這裏是對於順序圖的處理部分。
這裏是對狀態圖的處理部分。
作業3
作業3則是在作業2的基礎上添加對錯誤數據的檢查，整體架構沒有什麼大的變動。關於錯誤數據的檢查，也是層層分配到下一級的類中進行處理，直到分配到與該錯誤數據密切相關的層級進行真正的處理，並再逐層返回。由於整體架構與作業2一致，就不放UML類圖了。
期末時間緊張，就不自己畫UML圖了，希望老師理解_(°:з」∠)_
二、架構設計與OO方法理解的演進
在上這門課之前，我對OO的理解就是封裝、繼承、多態。那個時候我以爲，這一門課程就是會把封裝、繼承、多態的具體實現方式講清楚。現在來看，我那個時候對OO的理解還是TOO YOUNG TOO SIMPLE。OO不僅僅是封裝、繼承、多態，還有架構設計、編程方法的相關内容。
第一單元是層次化設計，其實就已經把封裝、繼承、多態的核心內容講清楚了。三次求導作業中，我主要思考的是我需要設置什麽樣的一個類，這個類是對什麽事物的抽象。如何合適地設計一個可以實現要求所需功能的類，這便是我第一單元對架構設計的理解。此外，這個時候我接觸到了TDD——Test-Driven Development。在開發代碼功能之前，先將單元測試用例寫好，這有助於在編程過程中對整體性的把握，可以避免在編程過程中的很多疏漏。但這個時候我還不太會用JUnit進行單元測試，因此沒有付諸實踐。不過，這是我所理解的OO編程方法的一部分。
第二單元是綫程安全設計，這個單元是對多綫程編程進行了一個初步的介紹。三次電梯作業中，我主要思考的是生產者-消費者模式的應用，進而拓展到對設計模式的應用。如何在自己的設計中合理的應用不同的設計模式，簡化自己的代碼，這是我第二單元對架構設計的理解。
第三單元是規格化設計，這個單元引入了規格的概念。這個單元中，結合OS課程的“抽象與權衡”的思想，我較爲深刻的理解了抽象的思想。而規格，就是將編程過程中的行爲抽象出來，將行爲從具體的代碼實現分離出來的一個表示方式。雖然JML不是很好用，但是將行爲與代碼實現分離的思想很符合面向對象的設計方法。我可以確定某個模塊的行爲，但是其具體實現卻可以隨意替換，只要可以實現該行爲，我可以采用不同的容器、不同的算法、乃至不同的子架構，這對於我之後的編程具有十分積極的影響。
第四單元是模型化設計，即用UML來表示架構設計。UML圖很直觀，可以表示的場景也很多，果真不愧被稱爲“統一建模語言”。通過UML語言，便可以將架構設計與代碼實現徹底地分離開來，我可以不用考慮使用Java還是C++，但是我卻可以把我的程序架構設計出來，這就是UML的奇妙之處。此時我對於架構的理解就不再依賴於某一種編程語言，架構設計就是一個獨立於編程語言的過程。
以上便是我對架構設計與OO方法理解的演進。
三、對測試的理解與實踐的演進
測試是保證程序正確性的必要手段。沒有人可以保證自己在寫程序的時候從來不會寫出bug，而測試便是消滅這些bug的重要方法。
第一單元，我看到有很多同學使用python和cmd搭建數據生成與自動對拍脚本，於是我也嘗試搭建了一個。雖然數據是隨機生成的，但説實話效果還真不錯，我的第二次作業就在提交前一個多小時被發現了一個“敲錯了一個字符”導致的bug，而且還幫助我在互測中收穫了一些成果。這裏的自動對拍脚本優點是可以自行進行測試，省去了人工測試的成本。缺點1是數據完全是隨機生成的，沒有針對性，需要補充人工構造的特殊樣例，此外還有缺點2是搭建需要消耗較多精力，如果有新的項目，甚至於對老項目進行迭代，都需要對評測脚本進行修改，評測脚本的可移植性極差。
第二單元，由於是多綫程，需要依照時間進行輸入，我使用python的subprocess模塊進行數據的處理與定時輸入。這個單元我沒有進行數據自動生成的工作。多綫程bug的出現是偶然性居多，同樣的測試數據運行不同次，結果可能都不一樣，因此生成隨機數據的意義就不是很大了。這一單元我主要采用手動構造測試數據，並使用python幫助我進行特定時間點的輸入，因此在測試上是比較樸素的。
第三單元，我接觸到了JUnit。JUnit與規格的搭配簡直是絕配，我根據每個方法的規格，對這些方法的行爲進行了大量的測試，效果非常好。從第一次作業的JUnit樣例可以一直沿用到第三次作業，因此當我爲了改善性能而對程序代碼進行大批量修改時，就可以在修改完畢後再運行一次單元測試，這樣便可以知道有沒有改出問題來。第三單元我完全沒有通過輸入輸出進行對拍測試，而完全將測試轉移到對方法行爲的檢驗上，感覺效果很好，用起來很舒服。
第四單元，由於臨近期末，時間較爲緊張，我的測試做的比較少。本單元的測試主要還是依賴於我對於極端情況輸入數據的構造上，對與JUnit的使用不是很多。由於我比較仔細地構造了較多情況的樣例，最後的強測結果還算可以。
四、課程收穫
- 簡單理解了面向對象的哲學思想（並不算深刻理解，還需在日後的學習中繼續感悟）。
- 大致熟悉了Java語言的使用。
- 瞭解了git、Typora(MarkDown)、StarUML等一系列工具鏈的使用。
- 規範了自己的代碼風格。
五、一點建議
- 希望上機實驗可以有一些結果反饋。同樣也希望每次上機實驗的內容能再完善一些，盡量把一些令人疑惑與迷惑的内容都講清楚。//（我知道上機實驗是助教們根據教學過程中的需求，在開始實驗前不久才確定下來的內容。這樣的好處是題目的靈活性較强，可以隨時根據教學情況進行調整。但是感覺有些時候實驗題的嚴謹性還有一些值得商榷的地方。因此我想的是，是否可以將一些嚴謹性較佳的實驗固定下來，在每年延續下去，使得部分實驗在經歷了不斷地迭代之後，成爲OO課程每年的「精選實驗」。）
- JML單元最後的難度全部集中到了算法上來，對JML的學習反而是弱化了，所以感覺JML單元的內容可以再調整一下，減少一點關於算法的考察。//（光是Tarjan算法我就研究了一天半，結果最後還是出了點小錯誤，哭）
- 我不是很瞭解最後的總評成績是如何計算的，不過感覺可以在總評成績計算的時候可以考慮「去掉一個強測最低分」，因爲感覺OO這麼多次作業，即便是非常優秀的同學，也難免會出現「翻車」的情況。一次偶然的失誤不應當對最後的總評成績造成重大的影響，因此感覺去掉一個強測最低分是合理的。//（最高分就不要去掉了哈哈哈）
六、綫上OO體會
個人感覺，OO是本學期綫上課程中所受影響最小的一門課了。不需要現場上機（OS課設每周上機考試取消了），不需要期末考試（OS理論課期末考試綫上開卷了），只需要按時完成每周的任務，實驗課按時進行實驗就好了。
對於我來說，我覺得綫上的OO雖然少了許多和同學面對面的機會，卻可以使我更加獨立地思考如何去做每一次的作業、如何設計架構，對於OO的學習反而是更有幫助的。
此外在最後一次實驗課上，我家裏停電了，這應該算作我在綫上OO受到的最大影響了吧。電力因素的不穩定，可能會對綫上課程造成很大的影響。雖然概率很低，咋就恰好讓我給碰上了呢？【無奈】
最後，感謝老師和助教這一學期的辛勤付出，正是因爲你們的付出，才讓我們的綫上課程得以開展下去。也感謝一直在和我探討問題的同學，正是在交流的過程中我解決了很多個bug，也正是在交流的過程中我們能夠共同進步。
看上去OO課程已經結束了，但其實關於OO的一切才剛剛開始。加油吧！