OO第四單元總結

UML做業架構設計

這一單元的做業本質上是對數據之間的聯繫進行解析，並從新創建數據結構以方便查詢的工做，這就要求咱們瞭解各類UmlElement的結構以及他們之間的關係是如何組織的。

第十三次做業

在此次做業的架構上，首先是創建了MyUmlInteraction類，實現UmlInteraction接口，以完成各類查詢方法。因爲輸入數據不保證順序性，因此不能邊讀邊處理，而是要先將各類元素分類保存在相應的容器中。對於那些後續要經過name或id查詢的元素，都使用了HashMap存儲以提升查詢效率。以後經過一系列build*方法創建繼承、實現、關聯等關係，再把各類屬性、方法、參數加入到相應的類或接口中。

爲了方便類和接口管理他們的數據，我爲UML中「類」和「接口」的概念又分別開了相應的類。這樣一來，一個類（接口）有什麼屬性、方法、參數，實現了哪些接口，與誰有關聯，就都很是清楚了，並且更能體現一種從屬關係。更重要的一點在於，每一個類（接口）還能夠有一個指向父類（父接口）的屬性，造成一種樹形的結構，方便遍歷訪問。

第十四次做業

此次做業是上一次做業的擴展，總體的架構思路沒有太大的變化。須要調整的地方在於，此次要支持三種UML圖的查詢，這些方法的實現不可能都放在一個大的類中，因此理想的架構是對於每種圖的查詢分別在各自的類中實現，而後集中在MyUmlGeneralInteraction中實例化，最終將各類查詢操做委託給各自所屬的類。

在數據存儲和管理方面和上一次做業大同小異，都是有什麼元素就創建相應的容器，必要時再開新的類，例如圖中的State、StateMachine、Interaction。

本次做業我耗時最多的部分是實現模型有效性檢查，須要考慮關聯、實現、繼承的直接或間接關係，在遍歷時保證不重不漏。其實從難度上來講並不大，只是一些概念不太清晰，須要想清楚各類可能的狀況。

OO課程總結

對架構設計及OO方法的理解

OO課程的每一個單元做業都分爲兩到三個階段，這與實際開發中逐漸增改需求的狀況是相近的。若是一開始的架構是好的，那麼後續做業的擴展就相對容易。但於我而言，每每後續的做業會讓我意識到以前的架構設計並不理想，有時甚至到了不起不重構的地步。在這一次次的推倒重來中，我會漸漸明白什麼樣的架構是好的，怎樣才能寫出好的架構。好的架構的特色是簡潔、清晰、高內聚、低耦合、易維護、可擴展，這也是OO方法中很重要的一部分。具體來講，每一個類或方法都應只有一個明確的職責，只管理本身該管理的數據。對於有泛化關係的類應採用繼承來表現共性中的特性，但也要注意對於沒有層次關係的類不該濫用繼承。要合理設置屬性、方法的訪問權限，儘量將數據隱藏起來並提供相應的訪問操做。策略與機制分離，將功能模塊化封裝，下降依賴性和耦合度，使得更改某一功能的實現沒必要牽連太多其餘代碼。諸如此類的設計原則還有不少，總之個人狹義的理解是，能在一次次做業的迭代中保持結構清晰穩固、功能愈發健壯的架構就是好的架構。

對測試的理解與實踐

OO做業中用到的測試方法基本上就兩種：樸素地生成大量數據進行測試，和經過OpenJML、JMLUnitNG等工具進行自動化測試。

第一種方法，按照數據生成的方式可分爲人工手造數據和自動化批量生成數據，前者效率較低且通常只能覆蓋到一部分狀況，後者效率很高並且幾乎能覆蓋到全部狀況，但要求能正確編寫數據生成腳本。不管怎樣生成數據，爲了儘量的覆蓋到全部的狀況，咱們須要對輸入數據的各部分的各類可能進行組合；另外一方面，咱們要確保測試數據能讓代碼中的每一個分支都被執行到。此外，按照正確性檢驗的方式，這種方法還可分爲標準答案檢驗和對拍檢驗。前者的前提是能經過某種方法事先獲得輸入數據的正確輸出結果，這樣能確保斷定結果的絕對正確性。若是沒法獲得標答，那麼只能採起對拍的方式，即將兩人或多人的答案進行比對，對其中有差別的地方分析出是哪一方的問題。固然不排除會有輸出一樣的錯誤結果的可能性，只不過發生這種狀況的機率很低。

第二種方法，也是OO課程想培養咱們學會的測試技能，即經過JML工具鏈，自動化地生成測試樣例。說實話我對這一方面的瞭解不是很深，更可能是一些實驗性質的探索，瞭解了它能作什麼及其基本的原理。這種測試方法的好處在於，測試數據的生成全程自動化，且理論上能覆蓋到全部的狀況。但它的弱勢也是顯而易見的：學習成本高，須要花更多的時間在代碼中編寫JML測試相關的語句，這是有必定難度的。

我的認爲，可能在工業界，尤爲是那些不允許任何程序錯誤的場景下（如航空航天、軍事領域），使用JML相關工具進行嚴密的測試是必要的。但在OO課程的做業中，甚至是小團隊的實際開發過程當中，用最短的時間實現最高的效益多是選擇測試方法時更須要考慮的因素。

然而不管如何，JML是一門值得了解和學習的技術。

課程收穫

我在這一學期OO課程中的收穫是多方面的。

首先，熟練掌握了基本的Java語言。Java是一門跨平臺的面向對象編程語言，在學界和工業界都有着普遍的應用。正所謂「工欲善其事，必先利其器」，要學習面向對象思想，首先必須得打好語言的基礎。其實課程中對於Java語言自己的教學內容並很少，後期遇到了問題更可能是本身上網查找資料，經過各類文檔和博客，逐漸強化了使用Java的功底。從這個角度來看，這門課還培養了我自主學習和獨立解決問題的能力。

其次，對於多線程編程有了較深的理解。多線程編程是實際開發中經常會用到的一種技術，學習它咱們才能解決多模塊協做的問題，充分利用CPU的資源。多線程問題須要咱們使用合適的設計模式，對各線程間的同步、互斥有深刻的理解，全面和仔細地分析協做是如何進行的，這對咱們的思惟能力也是一種鍛鍊。

再次，對JML（Java Modeling Language）有了必定的瞭解。JML是基於「契約式編程」的一種規格描述語言，相比於天然語言註釋，JML更加嚴謹和清晰。咱們從兩個方面進行了訓練：根據需求撰寫規格，以及根據規格實現代碼。此外，咱們還嘗試使用JML工具鏈自動化生成測試樣例進行測試。不管體驗如何，學習這樣一門技術是有必要的，相信將會在將來的實際開發中使我受益。

從次，還學習了UML（Unified Modeling Language）的相關知識。UML經過可視化的圖形形式，幫助開發者對大規模、複雜系統進行建模，這對於設計面向對象的架構具備重要的意義。經過對UML文件的解析，得以深刻了解各類元素的結構和組織方式，以及檢驗模型有效性的原則，在這個過程當中對面向對象語言的特性也有了更深的理解。

最後，也是最重要的一點，就是對面向對象思想的感悟。它不是某一個具體的知識點，但倒是貫穿整個OO課程的靈魂。在每次做業的架構設計中，我對於面向對象的理解都有進一步的加深。具體的內容我已在前文中有過總結，但它的精髓遠不止架構設計這麼簡單。面向對象是一種編程技術，但它更是一種思考問題的方式，一種世界觀，一種哲學。世間萬物是廣泛聯繫的，它們之間的關係如此複雜，以致於不能孤立地只用過程式的觀點來描述事物如何運做。面向對象經過抽象造成類、層次、繼承等概念，爲咱們提供了一個全新的視角……

改進建議

1. Checkstyle中每行最多80個字符的限制我認爲不夠合理，編寫代碼時每每硬生生地把一句邏輯連貫的代碼拆成多行，僅僅由於屬性或方法名較多、較長。我的認爲在閱讀代碼時，莫名其妙的換行比一行稍長的代碼體驗更糟。建議將每行的字符數上限改成100~120。
2. 但願BUG修復能夠挽回強測中必定比例的分數。
3. 但願課程組能合理安排實驗課時間，避免再發生上午剛接觸的新知識下午就考的狀況。