OO-Blogs Unit4

這篇部落格對Unit4做簡單的介紹，並回顧一學期的OO生涯。

單元簡介

這一單元實現一個簡單的UML解析器，並做一些有效性檢查。

HW1

第一次作業是類圖解析器，其中可能導致較高複雜度的方法是查詢實現的介面，對每個介面和類預處理可以做到\(O(n^2)\)或\(O(n)\)。

這一單元資料生成比較麻煩，又趕上考期，故沒有寫自動評測機。但強測中也沒有出現bug。

HW2

新增了對狀態圖和順序圖的解析查詢。沒什麼可講的，大概是OO整個課程裡最簡單的一次作業了吧。

強測中沒有出現bug。

HW3

加入有效性檢查。其中容易導致問題的一個方法可能就是迴圈繼承了。事實上如果一個點在環內，那麼等價於他存在於他的可達集中。因此暴力的對每個點dfs看看能不能找到他自己就行了，\(O(n^2)\)

有意思的是，開這次作業強測的那一晚剛發完強測分獎，就掛掉了，蠻戲劇性的。

bug出在沒有考慮兩個點之間有重邊，原因是鄰接表項用的是Set，改成List就好了。

課程回顧

架構及面向物件思想

第一單元求導，用繼承關係構造出一個表示式樹，體會到抽象的重要性。也初步體會到了Java中用繼承關係解決問題的簡潔和優雅，從PO過渡到OO。

第二單元電梯，對“每個類只管理自己的事情”有更深的理解。對類做責任劃分，更多的體會到了架構設計的重要性。

第三單元JML，接觸到了一個雖然對人工閱讀略顯複雜，但相當嚴謹的一個建模語言，度過了輕鬆且美好的一個月。

第四單元UML，接觸到了一個相比JML更加直觀的建模方式，用各種圖進行建模，設計和分析過程中都有廣泛的應用。

測試

除了第四單元都寫了評測機，一三單元是基於對拍(sympy/同學)，二單元是spj。

資料生成部分，全部採用了隨機生成資料，這確實是一個簡單但難稱充分的生成手段。之所以選用隨機資料，是在沒有人工分析坑點的情況下，希望有更好的覆蓋性。除此之外，一般每次會手動構造幾個極端資料。

除此之外，我愈加感受到了靜態檢查的作用，這裡的靜態檢查主要指讀程式碼。

建議

1. 第四單元遊戲體驗極差，指導書有太多謎語，規則繁雜而混亂，很多關鍵資訊隱藏在討論區裡，顯然不能指望同學們不停的輪詢討論貼。我出的這最後一個bug就是在結束後才看到一個帖子裡有助教提示的。
2. 進一步，即使第四單元的指導書修好，我也沒有覺得這三次作業有多大的意義，我覺得甚至還不如訓練和那兩次上機的收穫大。前邊JML單元學了就用，可以有一些實際的體驗。寫解析器這種東西貌似有點脫離主題，到最後也沒有對UML做什麼實踐，也就很難有深刻的體會。也許任務設定形式不一定要侷限在寫碼+測試上？可以做更多的嘗試。
3. 我當然要感謝課程組為了後半學期給OS和複習留下充足時間而降低難度而做的努力，但前兩單元和後兩單元的差距不得不說有些大。前兩個單元中即有效能分，又有自主設計架構的餘地；後兩個單元沒有效能分，而且基本沒有什麼架構可言(沒有體現出一個好架構的優勢)。個人體驗，為了效能，總會或多或少的失去一些架構的優雅。如果能有一個沒有效能分而專注架構設計的單元，更能凸顯OO思想對架構設計的指導作用，整體體驗會更好。

收穫

上面提了一些建議，但區別於傳統課程，總體上不能否認課程團隊採取了很多嘗試並且取得了不錯的效果，作為一門實踐為主的專業課，專業性和娛樂性共存，很大程度上充實了我的這一學期。

個人收穫上，前面已經說了一些。顯然最重要的收穫還是對面向物件思想的理解，這一點收穫不僅來自理論課，作業，應該說很大一部分還來自閱讀Java官方包的程式碼這一過程。很多情況下，用語言來描述面向物件思想不一定是最好的選擇，去看一看別人寫的OO可能更能領會其精髓。

更多注意到了架構設計的重要性，程式的程式碼複雜性、可讀性、正確性很大程度上取決於架構。

豐富了正確性檢驗的手段。從大一程設ds的純靜態檢查到自動評測機，覆蓋性更強。同時注意到邊界測試的重要性。

感受

總之，這一學期的OO就到此為止了。要說也有遺憾，比如由於評測機開發的滯後導致掛過一個強測，還摸了一次互測。整體工作量不算小，時間也相當緊湊，雖然最後還摸了個獎，但還是總有種劫後餘生的感覺，可以說是相當刺激了。

工程問題是一回事，但面向物件思想並不是簡單的工具。OO思想在軟體設計中自然有很大的作用，但作為一個架構設計思想，軟體設計可能只是其中一個領域。在很多涉及到管理的地方都可以見到面向物件思想的影子。從這個角度說，影響的廣泛效能給一個思想的魅力加分不少。