OO_Unit4總結&課程總結

本單元的作業是UML圖的解析，作業的目的一是進一步強化架構設計能力，學會如何一步步將一個複雜的圖結構進行多層解析。二是學習UML這一種強大的形式化語言，熟練掌握並應用到今後的程式設計與軟體開發中。從難度上講，本單元的難度相較於第三單元又有所回升，不過對時間複雜度的要求有降低。難度接近第一單元，但由於三次作業之間相互牽扯並不嚴重，因此一般情況下不需要進行程式碼重構。

1、本單元的架構設計

第一次作業

第一次作業的UML類圖如下：

本次作業中，基本把UML類圖的元件分成三層

• Class，Interface
• Operation
• Parameter

在呼叫主類的方法時想找到相應的查詢元素，再逐層下降，從而呼叫低階類中的同名方法，查詢到需要的結果。

這樣的架構有一個潛在的問題是低階類無法查詢高階類的屬性（一般是表），因此設定了一個靜態類，作為“總表”，一般裝入id等索引，供低階類進行查詢操作。

第二次作業

第二次作業的UML類圖如下：

第二次作業針對順序圖和狀態圖，同樣進行分層。

順序圖：

• Interaction
• Lifeline
• Message

狀態圖：

• StateMachine
• State
• Transition

同樣是上層類不斷查詢到下層類去呼叫方法，下層類通過總表查詢上層類的屬性。

在本次作業中出現了一個類中方法過多導致超過500行的問題，因此強行拆類，將三個圖的方法放在三個分別實現了相關介面的類中，並將這三個例項物件作為主類的屬性，主類在呼叫方法時只需呼叫這幾個分類的方法即可，節省了單個類的行數。

第三次作業

第三次作業的UML類圖如下：

第三次作業加入了模型檢驗。由於我在前兩次作業中，關於繼承，實現等關係全部都在END_OF_MODEL後預處理完成，所有的查詢指令只需直接查表。所以在這次作業中，我的這種寫法需要改動的幅度就相對較少。只有R002需要額外新添方法，其餘只需在已有的方法中進行判斷並將錯誤類移入表內即可完成。

此次作業中錯誤訊號的傳遞方向是由下層到上層的逆向傳遞，因此全部採用總表實現，模型檢驗類只需從總表中拉取資料即可。

2、四個單元中架構設計和OO理解方法演進

第一單元

在進行第一單元的時候，由於此前沒有經歷過這麼大程式碼量的程式設計（計組個人覺得稱不上程式設計），因此整個人完全沒有架構意識和麵向物件意識，還是處於一種寫一行是一行的狀態，整個三次作業下來的過程十分艱難。

第一單元對我來說最大的特色就是“重構，重構，再重構”。由於在編寫程式碼時對增量開發考慮的不夠多，因此每一次作業的架構都完全無法支撐下一次作業。當時一度對OO這門課感到絕望。

第二單元

第二單元著眼於多執行緒，是一個難度很高的單元，但我為了儘快培養自己的架構能力，於是頂著多執行緒的學習壓力，不斷思考自己應該進行怎麼樣的架構設計。相比於第一單元，第二單元的“面向物件”感更為強烈，各個執行緒之間的工作之間也更需要體現一個條理性，以及對執行緒安全的思考。

第二單元出現了一次史詩級大爆炸，強測中四個死鎖讓人猝不及防，最終還是採取暴力方式進行debug的。

我們至今仍未知道那天電梯死鎖的原因。

第三單元

第三單元是JML約束程式設計，由於每個需要實現的方法都已經給予了限定的規格，因此這個單元可以說是在強行糾正學生的架構設計習慣，在本單元中，面向物件的思想體現的十分明顯，每一個類呼叫其自身的方法協作工作，共同完成一個網路圖的構建。

第四單元

第四單元也是類似圖論的設計，這個單元雖然沒有了那麼嚴格的規格，但是我在寫程式碼的過程中可以明顯的感受到，前一單元中面向規格程式設計培養了我寫程式碼的好習慣，無論多複雜的結構，我都可以進行很有條理的分層建構，規劃實現。直到這時，我才感覺自己算是開始把握到OO這門課的脈絡，開始理解一個面向物件的大型程式設計應該做成什麼樣。可以說，在這四個單元的不斷學習中，我的架構設計能力與面向物件思維在不斷的進步，這門課為我今後進行程式設計打下了不可替代的基礎。

3、測試理解與實踐

不同於計組全程在討論區白嫖測評機和測試資料，在OO課中我在每一次作業都進行了測評機的搭建與測試資料的編寫。由於高工的學習壓力比較大，對於像我這樣的程式小白來說，一個人折騰出一整套具有完整體系的評測機較為困難，因此，我們建了一個“小圈子”，幾個同學在一起互相分工，搭建具有完整功能的測評機。

測評機主要分為三個部分，即驅動，資料以及評測。整個驅動部分基本完全由室友dl完成，從自動編譯到執行，以及可能出現的多程序併發與TLE程式殺除，一條龍服務。只要把專案檔案放在對應的資料夾中之後，其餘工作都可以全自動的完成。（他還寫了個郵件系統）

FJHNB！

資料生成在四個單元中略有不同。

第一單元的資料主要運用正則表示式進行生成，其中涉及到遞迴下降原理，第一次接觸時可能較為困難，但理解之後會發現資料生成的程式碼量並不大。

第二單元的資料基本全隨機實現即可（當然也可以針對性的構造較強資料），寫起來較為簡單。

第三單元的資料理論上也可以全隨機（當然這會導致瘋狂異常，整個資料下來沒有幾行有效的就是了）。另外一種方式就是在資料生成器中也構建網路圖，這樣可以地毯式排查所有可能的錯誤項。第三單元的資料基本全部由我完成，1400行的生成器化作死神的鐮刀，只需要一個測試點便能將一個程式除效能問題以外的所有錯誤全部暴露。

第四單元的資料在實現原理上與第三單元類似，但相對更加複雜，不過如果不追求用一個測試點將有bug的程式碼hack的體無完膚（也很難吧應該），實現起來也不會特別困難，只要測試的測試點夠多，一般的錯誤也可以被查出來，只是可能有點晚而已。

評測部分是對執行結果的檢驗。也許是巧合，前兩個單元每個人的輸出可能不一樣，無法對拍，但直接檢驗結果正確性的程式相對簡單。後兩個單元若想直接檢驗結果，不亞於重新寫一遍OO（還得保證不錯），但由於每個人輸出相同，通過對拍即可。

第一單元的正確性檢驗採用的是python中的sympy庫，可以幫助實現求導。

第二單元的正確性檢驗採用的是狀態機原理，針對電梯構建狀態機，若落入異常狀態則說明程式錯誤。

除了測評機搭建之外，還構造了相對極端的手動資料進行測試，也找到了一些bug。

4、課程收穫

毫不誇張的說，OO是我上大學以來，我認為學過的所有課中最有用的一門，沒有之一。

首先，這門課讓我第一次接觸較大型的程式設計，之前學習C語言和資料結構時，基本都是針對某一種演算法寫一個小的程式碼，這也是OO一開始感覺自己架構設計比較差的原因。但經過這門課之後，我今後再拿到一個較大的程式專案會知道從哪裡入手，怎麼去進行設計，這可以說是一個計算機系的學生質的飛躍。

其次，這門課讓我學會了如何去對程式進行測試。搭建測評機即能幫助找到自己程式的bug，也能進一步的鍛鍊自己的程式碼能力。這種能力在今後的軟體開發中也十分重要。

再者，OO課鍛鍊了我的協作能力，在整個課程的學習中，沒有同學們的互相幫助，我們不可能在每次作業中都進行很好的測試。

5、三個改進建議

1. 在pre中可以新增一些內容，讓同學們提前接觸到多執行緒（最起碼是瞭解）的內容，否則在第一單元結束後進入第二單元會非常，非常，非常痛苦。有必要的話開設前導課程。
2. 增開檢視實驗成績的渠道。OO每次課上實驗的內容都十分的有代表性，能增進我們的設計能力和對理論知識的理解，如果在進行完實驗後能得知成績的話，會得到更好的反饋效果。
3. 指導書在編寫的時候可以更加註意一些語言上的細節，讓同學們能夠順利理解，不產生歧義，這樣也能減少討論區中因為指導書文字問題而產生的過量時間消耗。

在這篇部落格完成後，OO課程也就告一段落了。

12次作業，4篇部落格，8次課上實驗，1次研討

我曾因為一個本地似乎永遠也測不出，卻連中測都過不了的bug寢食難安，用到了最後一次無代價提交機會才將測試通過。

我曾因為強測中突如其來的死鎖而猝不及防，將自己的整個程式來回翻閱，去尋找可能的疑點。

我曾因為研討課上因為一個不嚴謹的敘述被同學毫不留情的當面指出，萬分尷尬。

我曾因為寫程式碼時的疏忽，讓提交的程式碼中出現了個人資訊，幸好提前發現，萬分焦急的去找助教解釋才得以解決。

這門課給了我太多太多打擊，讓我摔了無數個跟頭。

但我清楚地記得，每一次強測拿到滿分時，內心的無比喜悅。

但我清楚地記得，每一次在找出自己的一個bug時，那種緊張和慶幸。

但我清楚地記得，在自己理解需求原理後，給身邊同學講解時的自豪。

我時常在想，這門課帶給我的是什麼？

學習一種新的語言？程式碼練習？還是更高的分數？

或許，更多的是一種跨越，讓我從一個只會埋頭寫程式碼的小白，到一個能敢於去挑戰軟體設計的程式設計師的跨越。

“OO”，這兩個圓圈，就好像一副望遠鏡，讓我的視野更加寬闊，能看到更多從原來學習的課程中看不到的東西。

而這些東西，正是成為一個合格的程式開發者所必須的，或是基本能力，或是核心素養，或是在面對一些事物時展現出的心態。

或許在多年以後，我不再記得清楚這門課的內容，不再能說出我在作業中究竟寫了些什麼。

但我相信，這門課對我的改變，對我的塑造，是永遠無法被抹去的，它會貫穿我的整個人生，並時時刻刻，默默發揮著作用。

那些曾在清晨，在傍晚，在宿舍，在圖書館，在課間，在課上完成的程式碼。

那些曾為了完成作業熬下的每一夜。

我們，

就此別過。