OO第四單元——終章

• 2020 年 6 月 17 日
• 筆記

一.架構設計

　　這一單元的作業主要是圍繞UML來對我們的面向對象思維進行訓練，剛開始接觸的時候或許因為些許陌生而覺得有一定難度，但隨著一次一次的程式碼閱讀再加上思考，逐漸地也變得得心應手了起來。

　　1.第一次作業

　　本次作業最終需要實現一個UML類圖分析器，可以通過輸入各種指令來進行類圖有關資訊的查詢。

　　在剛下載完官方的源碼時，面對規模龐大的程式碼，我一時也不知道從哪開始讀起，便硬著頭皮直接開始按循序閱讀，結果還沒讀完幾個java文件，我就感覺讀不下去了，一是因為有很多語法我並不是特別熟悉和了解，還有就是覺得讀完似乎對這次作業的需要完成的程式碼沒有什麼幫助，便直接打開需要實現的介面程式碼，結果發現有很多類都需要我去使用。後來在和同學的討論下，，原來只需要把element文件夾中的程式碼都通讀一遍就基本上沒有什麼問題了。

　　在參考了討論區後，我便做出了以下的層次設計，首先增加了一個介面TopClass，並創建了兩個類MyUmlClass和MyUmlInterface分別實現這兩個介面，以便後續的對這兩個類的調用，並考慮到方法可能較為複雜，便又創建了一個MyUmlOperation類，用來管理參數。在每一個對應的MyClass中，我都存儲了官方包中自帶的類，以便於獲取ID和name。

　　2.第二次作業

　　在第一次作業的基礎上，第二次作業要求我們擴展類圖解析器，使得可以支援對UML狀態圖和順序圖的分析，可以通過輸入相應的指令來進行相關查詢。

　　其實只要按照第一次作業的思路來進行建構，第二次作業並不是很難，就是增加幾個類，恰當地管理存儲某些數據。不過為了程式碼風格和進一步的劃分各個類的職責，我又新建了一個ElementAnalyse類，用來將傳入的所有的element分辨管理存儲好，然後主函數直接調用get方法即可獲得處理好的類圖，狀態圖和順序圖的數據，並進行後面的操作。在第二次作業中，因為需要用到狀態機，所以我專門創建了一個MyStateMachine類，用來管理UmlStateMachilne，這個類中存儲的即是那些需要管理的數據。對於狀態圖的管理，我同樣創建了一個MyInteraction類，其中存儲了生命線和各個消息，方便進行統一管理。

　　3.第三次作業

　　第三次作業與前兩次不一樣的是，在上次作業基礎上，擴展解析器，使得能夠支援對UML順序圖和UML狀態圖的解析，並對模型進行有效性檢查。

　　所以第三次作業如果是在前兩次作業已經有了好的框架之後，便只需要實現一些函數即可，我便是在交互的主函數中實現了那8個介面，並在我自己的管理三個圖的類中增加了一些判斷的方法，總體的架構和前兩次相比較基本沒有什麼變化。

　　4.這三次作業的bug情況與反思

　　對於第一次作業，我剛開始抱著應該很簡單的心態，試圖在周六最後一天可以完成，結果萬萬沒想到的是，實現起來還是有著一定的複雜度的，所以沒有及時的完成，成了我的第一個未提交的作業，但後來在與同學的討論中，逐漸地完善了自己的架構，這次作業也就算是完成了。而對於第二次作業，因為有個地方沒有加上判斷是否已經訪問過就直接進行訪問，導致出現了死循環，對應的強測也就出現了ctle，但在發現問題後及時地改正了bug。至於最後一次作業，或許是因為沒有太注意題目的意思和各種特殊情況的討論，導致在判斷rool0的時候忽視了對名字為null的討論，wa了好幾個點，最後在修復的時候加了特判便通過了。

二.四個單元的架構總結

　　剛開始接觸OO的時候,並不太注重整體架構的設計,往往是想好了實現的演算法,便直接像數據結構那樣,開始了方法的編寫,偶爾新建的幾個類就像struct一樣,一點也沒有體現出oo這門課的精髓和思想,在第一次作業中,輸入輸出中間處理的所有內容幾乎都擠在了一個類里,到後來的時候分出來了輸入處理和輸出處理以及化簡的過程,再到後來對每個類都進行精心的設計,或許這就是架構設計的慢慢進步的過程.到第二單元多執行緒,這時候架構的作用更體現了出來,如果不像老師上課講的那樣設計不同層次的類以及處理類的時候,整個工程可能會變得不堪重負甚至漏洞百出,當然為了提升性能我們不應該只看重演算法,更應該仔細想想如何讓在結構的設計上讓程式碼的水平更勝一籌.而像第三單元JML,在第一次作業相信大部分同學都犯下了翻譯需求的錯誤,沒有重視到整體架構的設計,導致出現了千奇百怪的錯誤,也就是那次作業,讓很多同學的爆0,沒有進入互測,所以在接下來的後續兩次作業中,我們都開始將重點放在整體的架構設計上,讓程式碼的品質進一步提升.最後一個單元則更是如此,演算法的方面其實完全可以被層次設計和架構設計所替代,只要架構設計的夠好,演算法再差整個工程也不會差到哪裡去,這一單元的作業就是完全由我們自己來設計,指導書上並沒有給出任何的提升,當然,這次訓練也讓我們的OO思想得到了極大的升華.

三.四個單元的測試概況

　　當然,我們學習OO課並不僅僅是學習編程思想,工程思想和那些總體架構的思想,我們的測試水平也需要在OO課的學習中不斷地進步.在第一單元的測試中,我完全採用了自己編寫java程式創建測試數據隨機測試的數據模式,一邊電腦在生成數據,一邊shell文件在自動測試對比,大量的隨機數據總能將bug測試出來.第二單元也是如此,只不過使用pathon生成測試數據要更簡單一點,仍然是通過自己編寫的自動評測機自己在完成大規模的數據測試.到第三單元時,我開始逐漸地使用起來JUNIT來作為輔助測試,單元測試的話更有說服力,測試的力度更大,範圍更廣,但是數據仍然需要自己去構造,JUNIT的最大的優點就是所有的程式碼都能被測試到,不留死角,但需要提前設計好測試框架與環境,這也需要一定的經驗和練習.對於第四次作業,同樣是採用JUNIT單元測試,再通過構造各種極端的樣例來達到測試的目的.

四.課程收穫

　　OO這門課是大二下學期和作業系統類似的大課重課,不僅難度大,需要我們花費的時間也很多,當然,有付出總有回報,在完成這麼多作業的設計與編寫,我的OO思想和編程思想也有了質的提升,再也不是僅僅拘泥於演算法的設計,而是更注重層次化,抽象,與架構的設計.往最差的情況去想,JAVA這門語言也算是被我們熟練的掌握了.這門課帶來的收穫絕對不止停留在java這個語言上,對資訊領域的任何地方都有著不小的幫助,因為不管什麼項目都需要設計,設計都會用到這些方方面面的思想,相信在以後的工作和學習中,這門課所教會我的思想將一直陪伴在左右.

五.具體改進建議

　　(1)第一單元的作業難度對於剛開始接觸OO的同學們來說難度可能有一點大,可以在寒假的預習作業中更多地去設計一些相仿的地方,減小同學們學期開始的壓力.

　　(2)研討課討論的時候對於有些問題可能是一知半解或者不知道答案,直接找同學回答可能不是什麼特別好的主意.

　　(3)第四單元的第一次作業的指導書上可以增加以下對閱讀官方程式碼的建議與提示,要不然太多的程式碼對於某些同學來說可能是一個極大的挑戰.

六.線上學習感受

　　感覺OO這門課線上線下的區別不是很大,除了見不著英姿颯爽的老師們和可愛的學長學姐們(似乎沒有學姐),其他的沒有什麼太大的變化,就是在寫作業的時候不太方便與同學互相debug與交流,其他的問題都不大.還有就是上理論課的時候並不能直接和老師語言交流,少了一點氛圍,但錄播課的好處就是可以在不懂的時候看回放,加深理解.