OO第二次博客做業

第七次做業——出租車

本次做業是模擬出租車和乘客交互的系統，對於在地圖中的乘客發出合法請求以後，出租車先到乘客地點接單而後再將乘客運送到目標位置。
本次做業中主要須要處理的問題是如何將gui類本身的代碼耦合，正常顯示出圖形界面；如何設計接單窗口時間限制，如何知足多線程安全。
在類的設計上有輸入輸出處理InputHandler和OutputHandler類，線程有RequestDeal和Taxi，而且由於每一條請求有一個3s的開窗時間，因此對於每條合法請求設計了一個Window窗口線程，處理的結果做爲命令傳入給選中的出租車。
本次做業中進步之處能夠從度量分析中看出來，對於類的抽象更加明確，同時方法的功能相對前幾回更加單一，沒有出現God類和Idiot類。

（1）類圖

類圖

（2）度量分析

從度量圖能夠看出大部分抽象作的不錯，方法的功能比較單一。
另外Window類的SendTaxi（）方法仍是抽象程度不夠，在寫的時候也沒有注意將其拆分出獨立的單元，這種寫法應該在後續做業中避免；另外就是Taxi的計算路徑類，每次都會計算一遍最短路徑，增長了計算開銷，應該能夠將第一遍計算的結果保存下來，節省時間開銷。
（3）時序圖

UML圖

（4）Bug分析：
本次做業中不足之處是沒有對輸入進行嚴格處理，因此在寫判斷條件的時候隨手寫成了下面這種：

if (srcx < 0 || src > 80)

致使掛掉了兩個對於80邊界條件判斷的公測點。
還有一個問題是多線程不安全的設計，對於搶單的隱藏問題沒有考慮到，因此同一地點的不一樣乘客連續搶單以後，若是搶到同一輛出租車則這兩出租車只會相應一個請求，掛點了一個公測點。改進就是在對搶單出租車進行篩選的時候剔除已經被其餘乘客選中的便可。

（5）對面Bug：
此次對面做業沒有Readme，最開始測試的時候沒有導入地圖文件，因此程序一直Crash，這是一個沒有對文件輸入處理try-catch的bug。還有兩個沒有對合法輸入斷定的bug。

第六次做業——IFTTT

此次做業是實現一個監控程序，若是監控範圍內的對象屬性發生變化，就會觸發觸發器產生對應的措施。監控內容可使文件夾也能夠是文件，做業的目標是針對線程安全進行設計，若是平衡共享對象的問題。
此次做業的設計上出現了問題：在和同窗交流的時候發現他們都是將監控文件和監控文件夾做爲一個總體編碼，也就是說文件是文件夾中只有一個文件的狀況，而我則是將監控文件和監控文件夾做爲兩種狀況處理，這種處理方式雖然可以實現功能，可是無疑提升了核心算法的代碼量，若是有什麼修改則要同時修改兩個部分的代碼。

（1）類圖

類圖

從類圖能夠看出Trigger類的方法比較冗餘，其中斷定文件和文件夾的方法原本是能夠合併在一塊兒的。
（2）度量分析

從度量分析可知，對於InputHandler類的work方法處理過於籠統，其實能夠拆分爲檢查格式和提取參數的

（3）時序圖

UML圖

（4）Bug分析：
在公測中遇到了惡意扣分的狀況，對面抓住issue44助教的一句話認爲我四個公測點都有bug：沒有改變的屬性要所有輸出，固然這種狀況申述就處理了...
考慮不周全的是在文件夾下添加文件夾或者文件不能實現監控，是由於最開始只使用了一次快照，另外就是當文件被刪除的時候size被認定爲改變爲0，程序中沒有對刪除後的文件進行監控對比。

（5）對面Bug：
策略是首先使用單個數據單線程進行測試，若是沒有問題再測試多線程，而後測試文件讀寫衝突狀況。
抽到的做業出現了不少問題，在閱讀他的源碼後發現沒有寫path-changed斷定，對於觸發器的recover也不能實現。

第五次做業——多線程電梯

第五次做業因爲最開始接觸多線程，同時程序抽象作的很很差，最終捎帶都沒能實現，具體分析Bug就沒有必要了，從類圖中能夠看出對於類的設計也很是有問題，好比在Main中添加了不少對於輸入的判斷方法，main主體也包含了不少應該抽象成方法的代碼，多線程電梯抽空再重構吧。

類圖

總結

1. 第一次多線程電梯寫的很糟糕，花了大量時間最後基本功能都沒有實現，其中類的規模和不少方法的規模都太大致使維護成本高，修改的過程當中越改越亂...
   作後面的IFTTT和出租車做業時認識到從一開始就設計好是多麼重要，從出租車做業開始聽從了必定的設計原則（SOLID），減輕了不少編碼的負擔。
2. 雖然通過了三次多線程做業，可是目前仍是隻使用過synchronized和sleep關鍵詞，對於線程安全理解還不夠，併發編程還要多加練習。