OO第四單元總結

OO第四單元總結

1、第四單元做業總結

本單元主要有兩個任務：

1. 對UML類圖進行解析。

2. 對順序圖和狀態圖進行解析。

1.第一次做業架構分析：

做業內容：本次做業經過分析uml圖，將各個元素解析出來，將各個元素進行處理，構建一個查詢程序，使用特定指令進行查詢圖內關係

架構設計：本次做業運用了大量的HashMap，目的是將各個元素之間經過索引key查詢value。架構中主要使用的算法包含深度優先搜索DFS。

類圖以下：

2.第二次做業架構分析：

做業內容：本次做業在第一次做業基礎上增長了順序圖和狀態圖的內容，整體上內容相同，也是經過特定指令查詢圖內關係。

架構設計：本次做業運用了更大量的HashMap，將各個元素之間經過索引key查詢value。架構中主要使用的算法包含深度優先搜索DFS。

類圖以下：

3.第四單元教訓總結

本次做業存在的主要問題是未可以很好的設計要求類，以致於寫的太多太雜，沒有很好的分層設計，在checkstyle檢查時類超出了500行，費了大量功夫修復代碼style。

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

一、第一單元架構設計

本次做業的內容主要是多項式求導，可是由於第一次做業和第二次做業沒有很好的設計架構，第三次做業進行了重構，學習了遞歸降低的方式處理表達式，對做業需求進行一部分一部分的拆解，最終所有化成小問題來解決，這種思想是我在本單元學習中最爲深入的。

二、第二單元架構設計

本次做業主要完成多線程的設計。最重要的學習部分就是調度器的設計，經過單例模式成功實現了多線程之間的交互。將直接提出的需求與實現之間構建一個橋樑，相似於緩衝的設計，這個單元我還能夠在性能上面多作優化，本單元的代碼的可維護性也比較高，三次做業體現了明顯的遞進關係，達成了訓練的目標。

三、第三單元架構設計

本次做業主要完成JML語言的理解與實現，先寫規格後實現是一個很好的代碼習慣。本單元主要採用的圖搜索方法是Floyd算法，採用了簡單的三維數組進行Floyd的計算。做業的難度梯度和代碼的設計上有明顯的遞進關係，本單元徹底按照需求的增長而在原有的代碼上作少許的增長或刪改。本次做業在性能上能夠進行大量的優化，主要包含圖更新的時機，在查詢時若是出現路線的變動再進行圖的更新且僅更新一次是我這三次做業性能優化的主要思路。

四、第四單元架構設計

本次做業主要完成UML圖的解析以及圖內信息的查詢。最大的問題就是類設計上出現了超出500行這樣沒有很好架構的現象，但本次做業運用了大量的HashMap，大量Map的實用讓我感覺到了java真正的強大。

五、OO方法理解

在本課程中，四個單元的架構都是按照做業要求進行做業設計，但都缺少對於代碼架構的大局觀，尤爲是在第四單元，甚至一個類超出了500行。可是雖然總體架構上未能完成自上而下的設計，可是可以熟練地自下而上地根據需求設計。OO的設計方法根本上來講就是everything is subject，這樣的設計理念能夠將每個小的需求，都設置一個類，這樣能夠加強代碼的可維護性和可擴展性。

3、四個單元中測試理解與實踐的演進

之前理解的測試程序就是簡單的進行標準輸入，查看標準控制檯輸出。但隨着互測趣味的增長，有着測試大量代碼的需求，因此就本身嘗試着本身去寫腳本測試數據，尤爲是在表達式求導單元，還接住了別的工具對錶達式進行化簡最後比對錶達式是否相等。本身寫過數據生成器，可是感受本身的數據生成器可能有些簡單，仍是會出現代碼的bug測不出來的現象。可是電梯單元是沒有很好的學習如何自動檢測數據的正確性，因此可能那單元強測出現了比較大的問題。總之數據是在隨着需求變化的，測試也應該跟隨數據不一樣而採起不一樣的測試方法，這樣才能不斷進步。

4、課程收穫

本課程能夠說是給了我不少的思惟設計，不僅僅是學會使用java，相似於遞歸降低、分治策略、添加緩衝層等等這樣的設計理念在任何程序語言都一樣用獲得。雖然代碼自下而上慢慢完成需求是很天然地，可是我認爲好的架構須要在寫代碼以前就設計好須要哪些工具，須要多少類，採起怎樣的策略可以使代碼的可維護性和可拓展性提升，雖然還不能很好地理解這一理念，但我認爲這個課程已經給了我一個起點，我能夠在已經學習了的知識的基礎上進行更多的練習，代碼量不夠就用代碼量去補足，總能達到看見需求就有自上而下架構設計的思路這樣的一個境界。

5、立足於本身的體會給課程提三個具體改進建議

今年是OO課程的第一次大改革，雖然我沒有經歷之前的OO課程，可是我認爲這門課程是本學期最良心的，老師給力，助教樂意解答問題，這是一個很大地「用戶體驗」的提高。面向對象的設計思想應該說咱們只是入了個門，若是想熟練運用這一實用的工程思想，也許還須要多多進行代碼設計。給課程組的建議以下：

一、從新權衡中測數據的強度

雖然考慮到中測是須要考慮全體同窗平均水平的，僅僅爲了檢測是否完成本次做業的基本需求。可是每每會由於代碼很小的疏忽，由於本身手頭數據不足，或者未可以考慮到課程組對於數據的設計意圖，強測成績不堪入目。雖然直接完成一份完善的代碼是一種能力的體現，可是畢竟寫代碼不像高考，即使輸入再多的心血設計本身的架構，可是隻要有疏忽每每容易形成滿盤皆輸的局面，但提升中測數據的強度能夠很好的改善這一局面。但願之後課程組能夠從新權衡一下中測數據的強度。

二、理論課增長對於代碼的介紹

理論課雖然是介紹理論知識，可是仍是但願可以有一些對於某些功能的示範性代碼，這樣不只能夠提升課堂的趣味性（由於我認爲讀代碼猜設計意圖自己仍是頗有趣的），還能夠將實踐和理論聯繫起來，也許效果會更好一點。

三、從新設計實驗課的內容

實驗課不少時候是不知所云，上午剛學的知識下午就要實現，這中間有點趕，缺少一個消化知識的過程。或許能夠考慮延長實驗課的持續時間，也能夠達到對於知識檢測的目的，不必定就要按照規定時間完成需求。