OO第二次階段性總結

終於，終於又到了寫博客的一週。能夠說這三週的做業相比前三週來講的確是翻車了，不過翻車當中也有進步，從多線程電梯的不知所措到最後出租車可以有條理的寫程序，感受本身在這三週做業當中學到的知識比前三次要多得多。

做業分析

多線程電梯

度量

類圖

時序圖

分析

此次做業是OO翻車的第一次做業。能夠說多線程邁出的第一步是很是艱難的。首先因爲做業由提早輸入改成實時輸入，之前做業的算數式運行方法能夠說徹底廢棄了。所以此次做業中我嘗試了模擬樓層和電梯按鈕的方法。此次做業當中我認爲最大的問題就是調度器和電梯關於捎帶的邏輯過於混亂。調度器和電梯中都有關於捎帶的判斷部分，而且整個電梯的多線程同步比較混亂，所以最後運行起來就會「缺斤短兩」，常常漏掉一部分能夠捎帶的請求。

此次做業拿到的他人代碼是一個大佬的代碼，仔細學習了其代碼後發現我本身的代碼果真耦合程度太高，一個方法一二百行。這一點在下次做業當中獲得了改善

IFTTT

度量

類圖

時序圖

分析

此次做業是OO翻車的第二次做業。多線程電梯後痛定思痛的我早早開始了IFTTT做業的研究，但卻在設計上花費了過長的時間，致使最後寫代碼的時間壓縮太多，而且當中不少奇奇怪怪的小問題沒有妥善解決。實際上後來在看過互測同窗的代碼後我發現我很大程度上誤解了此次的做業......

此次做業當中我設計了一個全局HashMap用於存儲和跟蹤文件的信息。HashMap當中，做爲Key的是一個由我本身設計的能夠惟一表示某個文件的字符串，Value則是封裝好的SafeFile對象。這個思路的初衷是爲了保證全局的修改只針對一個SafeFile對象（由於線程安全是放在一個對象上的），乍一想很是美好，由於Key能夠忽略SafeFile內部文件的變動而實時跟蹤。但這個思路存在着很是大的漏洞（而我發現的太晚了），即對於用戶的測試來講，用戶每監控一個文件都須要調用測試的方法，而測試中的方法和HashMap中的SafeFile創建一一對應很是困難，由於某個文件更名後，其Key並無改變，但接口並不能生成一個「以前的Key"。

實際上在看了互測的代碼後我發現，根本沒有必要保證這種全局的修改，由於可使用Snapshot的方式不斷掃描來解決。所以自創思路的風險仍是很大的，而且實現過程當中會有各類各樣的小問題。除此以外此次因爲debug時間太短，亂加synchronized致使最後寫入detail出現了阻塞，也所以跪了不少個公測點（他們產生的緣由都是同樣的...）

出租車

度量

類圖

時序圖

分析

此次做業終於站穩了沒有翻車。在IFTTT後我進一步對多線程進行了思考，發現分清楚何時要加synchronized很重要，以及不少狀況下根本不須要使用wait和notify，亂用反倒會致使阻塞的出現。此次出租車做業的需求也比較明確，爲了未來做業的可擴展性，我將地圖上的點和邊均進行了對象化，而且用邊來構成路徑讓出租車運動。此次做業中實際上線程安全的部分並非不少，並且主要的處理辦法就是給方法加synchronized，也沒有出現什麼大問題。此次的惟一BUG竟然是沒有注意到忽略同地點請求的要求，比較惋惜。設計方面沒有被報缺陷。

此次拿到的代碼沒有之前兩次那麼好了（說明掉段了），艱難的閱讀代碼後（代碼風格實在是emmm），發現了一些代碼邏輯方面的bug，以及報了一些設計方面的缺陷（主要是代碼風格比較差）。

心得體會

相比於前三次做業來講，這三次做業（尤爲前兩次）着實給本身澆了一盆冷水。最大的收穫我認爲就是，少空想，多寫代碼。碼代碼的過程當中伴隨思考纔是最好的方法，爲了完美而經過空想的方式提早計劃好是很難的，由於總會在代碼過程當中發現本身漏掉了不少細節。出租車做業中我想一點寫一點的方式效果就比前兩次拖到最後寫好不少。但願下一階段能夠繼續提高本身（找回段位）