oo總結II
多線程電梯
設計策略
用戶發出請求加入請求隊列，調度器根據電梯的狀態為電梯分配請求，每個電梯有自己的執行隊列，根據執行隊列的請求來改變自身的狀態。用戶請求處理器和調度器共享請求隊列，調度器和電梯本身存在對電梯狀態進行同時讀寫，因此需要對這兩個做數據保護。
一開始以為電梯是要模擬真實運行狀態，對時間不做調整，後來發現上下一層時間和開關門時間是非常精確的3.0s和6.0s，於是增加了一個時間系統來管理時間。另外，本次作業個人認為有一個最大的矛盾點，就是一方面盡管是同一行輸入的請求，即同一時刻發生的請求，還是會考慮實際調度情況存在實際執行的先後順序，另外一方面又要使同時輸入並且執行時間相同的請求同時完成。（實在難以理解）
這個矛盾點主要在於這樣的測試樣例：
(ER,1,5);(ER,2,5);(ER,3,5);(FR,6,DOWN)
END
如果存在調度順序，那麽FR請求應該分配給實際上先執行完的一號電梯，而不是隨機分配。
實際上這個矛盾還是能夠實現的，只不過懶得改了，只要用一個真的很假很假的時間系統就可以實現狀態同步了。
OO度量
在判斷電梯狀態選擇電梯分配時由於判斷條件多存在if嵌套過多，嵌套塊深度過大；另外，調度器schedule方法承擔了篩選同質請求，分配請求的功能，致使圈復雜度過大。
類圖
優點：請求類使用了繼承，減少了屬性數量
缺點：調度器類承擔功能過多
時序圖
設計原則
違背了單一職責原則，電梯狀態的改變應該由電梯本身完成，而不是由調度器的command方法來改變。基本符合其他設計原則的要求。
IFTTT
設計策略
這次作業的設計主要在線程上糾結，糾結一個監控任務一個線程還是一個觸發器一個線程，最後還是選擇了後者。所以在監控掃描文件時，由於一個觸發器有多個觸發任務，監控上由於存儲順序存在時間誤差，只能要求測試者每隔一段時間做一次晚間操作。另外，由於記錄觸發信息用的是同一個輸出流，所以要對Summary和Detail加鎖，防止出現同時輸出。
OO度量
類圖
優點：構造了觸發器類，一個觸發器一個線程，減少了線程數量
缺點：文件類沒有真正實現文件安全，觸發器類由於線程運行順序的原因在同一個周期獲取到的文件快照可能不一樣
時序圖
設計原則
對於觸發器類沒有使用繼承，沒有將幾個觸發器的共性抽象成父類，違背了重用原則
出租車
設計策略
這次作業沿用了很多多線程電梯的設計策略，輸入處理器和調度器共享一個請求隊列，調度器和出租車可能出現同時讀寫出租車信息，所以對這兩處地方要做一個保護。由於時間也要精確，於是構建了一個時間系統，來統一管理時間。另外，為了統一管理100輛出租車的信息，構建了一個TaxiControl類來統一更新出租車信息。
由於更新一百輛出租車的信息和為訂單選擇出租車都要在200ms內完成，所以很多地圖信息需要直接獲取，如果在線程運行時計算則會耗費很多時間，所以在初始化的時候就把地圖信息計算好，包括節點間距離等等。
OO度量
嵌套塊深度過高，圈復雜度過高。
類圖
優點：按功能分類，職責清晰
時序圖
設計原則
此次設計經過較長時間的思考，基本符合各類設計原則。
bug分析
多線程電梯
①同時輸入且執行時間相同的請求由於多線程調度的不確定性沒有辦法同時完成
②程序輸入END有時不能停止
IFTTT
監控目錄時，有的重命名和路徑改變無法掃描到
出租車
無
尋找bug的策略
①看readme,看一些指導書沒有規定的內容，代碼實現和readme是否符合
②閱讀代碼，尋找邏輯錯誤，看是否實現了線程安全，並構造測試樣例來實現錯誤
③邊界測試，看能不能頂得住壓力
心得體會
①對線程安全有了更深的理解，對共享對象能做更好的數據保護
②設計構思更加用心，在構思的時候能有意識的遵循設計原則
③OO作業真的慘，真的慘，慘慘慘
oo總結II