oo做業總結報告2

第五次做業 多線程電梯

多線程同步和控制的設計策略

1. 明確類和對象，以及是否區分對象實例。具體類能夠從類圖中看出；
2. 明確線程的類型和數量。輸入做爲一個線程，調度做爲一個線程，三個電梯獨立工做，互不影響，分別是一個線程；
3. 明確線程之間共享的數據，控制同步，以及保證線程安全。輸入線程將輸入存放在請求隊列中，調度類訪問請求隊列中的請求，因此對請求隊列的操做須要作到互斥，即要加鎖；電梯線程接受到請求後處於運動狀態，其各個屬性參數在不斷變化，而調度器調度時須要訪問電梯的屬性狀態，因此爲了保證獲得的是準確數據，改變和訪問電梯狀態的操做須要上鎖，作到互斥；

類圖

　　

設計方案

　　此次電梯能夠看作是生產者消費者模型，其實發現，若是可以找到一種模型來適應工程，其實核心的設計模式就已經出來了。其中，當請求隊列不空時，調度器就從請求隊列中取請求進行調度，爲空時，調度器就須要等待，知道請求隊列中有請求是，再將調度器喚醒。而每一個電梯都有本身的執行請求隊列，當這個請求隊列不空時，喚醒該電梯線程，爲空時，等待，用到了兩次生產者消費者模型。其餘關於調度的算法和前兩次電梯基本差很少，就是多了電梯之間的選擇。

度量

OO度量

　　能夠看出，調度器的圈複雜度標紅了，複查代碼發現這個方法的代碼重複率比較高，三種狀況，基本是同樣的代碼，應該是當時懶了，設計原則的意識還很弱，致使圈複雜度較高；對於重複的代碼，即可以抽象出一個方法，用起來也十分簡明，複雜度也會有較大的改善。

Bug分析

       這次多線程電梯調試花了好久時間，因爲時間很緊，就只實現了基本的功能，對於指導書要求的嚴格的時間輸出，沒能實現，掛了幾個點。互測的時候拿到一個只能識別格式的代碼，基本功能都不能實現，因此測試也較爲容易，沒去深究更小几率的bug。

 

第六次做業IFTTT

多線程同步控制的設計策略

1. 明確類和對象，判別是否區分對象實例。從類圖中能夠看出該工程的各個類；
2. 明確線程的類型和數量。一個文件一個線程，一個目錄一個線程，三個動做三個線程。此次的線程類型是肯定的，可是文件線程的數量倒是動態的，不肯定的，須要根據輸入的監控文件對象個數來肯定，可是好在程序是在已經肯定了輸入後才真正開始運行，這麼說其實線程的數量也是肯定的。
3. 明確線程之間共享的數據，控制同步，以及保證線程安全。此次實現的是對文件的監控，以及觸發動做，由此引入了快照這一律念。文件屬性是做爲這次工程的核心，也是共享數據，全部的操做都是圍着它轉的，首先是有一個文件安全類，專門提供對文件的一系列操做方法接口，必須保證是互斥的，文件監控線程須要訪問文件的屬性，必須保證此刻獲取到的文件屬性是正確的以及最新的，比較過程爲和快照對比。

類圖

　　

設計方案

       總體的設計思路是根據輸入的IFTTT構造監控線程，初始化快照，當監控到變化須要觸發操做時，觸發相應線程的更新快照，快照是做爲監控線程對象的一個屬性存在的，監控線程保持必定週期的頻率掃描文件。

度量

　　

　　

度量分析　

　　對目錄監控的函數出現圈複雜度太高的現象，其中主要是用了兩重循環和if條件嵌套，對於目錄的監控，須要檢測目錄下的每個文件，而目錄下還可能有目錄，因此在和快照比較的時候嵌套就複雜了些，嘗試中發現要是將這個對比過程在抽象出一個函數，圈複雜度就會好不少，仍是須要注意單一性原則，實現功能模塊化。

 

第七次做業

多線程同步和控制的設計策略

1. 明確類和對象，以及是否區分對象實例。類圖中可見；
2. 明確線程的類型和數量。輸入一個線程， 調度器一個線程，100輛出租車100個線程，計算路徑的線程。
3. 明確線程之間共享的數據，控制同步，以及保證線程安全。輸入和調度器共享用戶請求隊列，因此請求隊列爲共享數據，須要保證互斥原則，調度器獲取出租車狀態信息，出租車自動改變狀態信息，因此出租車的狀態信息爲共享數據，須要保證訪問互斥。

類圖

　　

設計方案

       此次的設計和以前的多線程電梯有類似之處，實現實時調度，面對一個請求，選擇最優的車輛去執行請求，可是總體的複雜度感受比多線程電梯高一些。輸入線程將輸入放入請求隊列中，當請求隊列不爲空時，調度器遍歷請求隊列，爲每個請求尋找發送訊息的出租車隊列，其中每個請求控制在3秒的窗口期，當搶單窗口關閉時，就肯定了該請求的最後出租車隊列，而後再根據挑選出租車的原則選出最終執行請求的出租車，在這期間，計算線程一直在計算每個請求的最短路徑，並將最短路徑保存在相應請求的Point容器屬性中，出租車在啓程是必須確保該請求的最短路徑已經得出，其中對於最短路徑的計算須要保證互斥，由於函數中有一個距離數組是共享的。這樣執行效率是很低的，由於計算最短路徑比較費時，調度也不夠靈活，不可以將每個請求分離開。想過爲每個請求創建一個線程，但又擔憂本身維護很差，出了奇奇怪怪的錯誤，就沒這樣實現，後面會去嘗試這樣作。

度量

　　

　　

　　

度量分析

　　隨機化出租車運行路線函數，尋找最短路徑函數，以及調度器中的尋找合適出租車函數，這三個函數複雜度確實挺高的，感受稍微寫個兩層循環，以及一些判斷條件語句圈複雜度就會爆掉，可是要是將一個功能函數再進行拆分，有會感受這樣太過零散，調用的深度又會增長。在代碼的質量上還須要進行不斷的深究。

Bug分析

       此次做業我沒有交，由於沒有實現功能，本身在設計和實現的鏈接方面還十分欠缺，總寫出bug連連的代碼，準確的說是寫出的代碼和本身內心想的徹底是兩個東西，也許是coding的太少，因爲直接無效，因此並未進入互測階段，也沒有測同窗的程序，繼續努力吧。

心得體會

　　三次多線程，能夠說是作的一次比一次差了，是心態變了，仍是真的做業難度增長了，也許都有吧。但並非沒有收穫，最起碼本身仍是去設計了，學習了多線程的相關知識，去按照設計原則編寫了本身的代碼，雖然實現的效果不好。反應比較慢，邏輯能力欠缺，思惟也不夠縝密，在實現邏輯功能的時候容易出現bug（感受設計的時候仍是不夠細緻），而且完成代碼後的調試過程比較慢，可是時間又是有限的，因此結果並不如人意。我以爲本身在實現這些工程的時候確實是有困難的，不想只是爲了避免無效而交上一份質量很是差的代碼，這也是我第七次不交做業的緣由，反應慢就須要比別人花費更多的時間去學習，補給站也定是有它的意義所在，但可以正常避免不去補給站，就儘可能不去，不管在哪，目標只是想老老實實完成這門課的要求——2000行高質量的OO程序，但願本身能夠作到。