這一單元的作業在規定時間內提交上去並且通過了的作業只有第一次，後兩次作業都無效。第二次作業是自己沒有解決排程器的問題，其實原因還是在於第一次作業做的太過簡潔，第二次作業完全屬於重構，沒有一點需要用到第一次作業的東西，不過課下倒是稍微完成了一下，並沒有達到正確輸出的目的，總是會有邏輯上的問題，還有時序上的問題。第三次作業被限制在了cpu時間，wait和notifyall的使用不夠純熟，而且採用的是半傻瓜排程（下面解釋），也不知道會不會在中測卡住執行時間（只卡住時間提交了一次），以下進行這三次作業的具體分析和總結。
結構第一次作業用了極其簡單的結構，雙線程，三個類就完成了，uml圖如下：
很簡單的結構，電梯只進行指令的執行，並且可以通過輪詢方式訪問請求列表是否為空並且進行執行緒自主判斷是否終止，請求列表進行指令訪問，主線程進行指令的輸入並且存入列表，沒有使用任何時序上的判斷，也不存在共用物件的衝突（乙個存乙個取），所以第一次作業會完成的比較快。優點：快速簡單，既熟悉了多執行緒程式設計，又能夠實現簡單的單部電梯模型。缺點：不容易進行擴充套件，直接影響第二次作業的進行。方法數一定是電梯比較多，但是邏輯都部署在主線程，進行執行緒的執行和終止。
測試測試方面倒是並沒有大問題，互測階段也沒有被hack出bug。
結構第二次作業相應的uml圖只是在電梯和請求列表之間加了乙個排程器執行緒，變為了三線程模式。這裡沒完成就不做展示了，排程器執行緒和電梯執行緒是第二次作業的兩座大山，電梯執行緒我完成的應該到九成，但是奈何沒有時間和精力搞定排程，極度的疲倦以及身上陣陣發麻的資訊告訴我應該珍愛生命，就這樣放棄了這次作業，究其原因，其實我感覺還是出在了最初紙面上的設計階段，沒能細化，只是單純地認為加上排程器進行指令的判斷呼叫就可以，忽略了電梯本身執行的邏輯其實也是乙個巨量的工程，結果兩頭沒能兼顧，翻了小船。
結構第三次作業吸取第二次作業的教訓，早早動工，注重保養，請教大佬······還是翻了車，話不多說，上uml類圖：
上面dispatcher類只是乙個方法，目的是進行指令的判斷和切割，即對新進來的指令判斷是否需要兩部電梯協作才能完成，如果需要則進行最優拆分（即不考慮電梯狀態的情況下，用時間最少），並且將拆分指令插入請求列表中。scheduler進行指令的分配，並且處理分割指令的執行順序。由於第二次作業並沒能實現可稍帶，整體電梯內部使用傻瓜排程。優點：沒啥優點，可能多執行緒之間的協作做的還不錯，缺點：就是wait和notifyall不會使用。在測試時改成whlie sleep是可以執行的，上交的那份作業是使用while sleep模式的，但都是real time error，cpu時間不符合。
提前動手！提前動手！提前動手！
多交流，第三次作業深刻體會到這個道理，如果不是同學好心說了幾句結構上的簡化建議，我可能就像第二次作業那樣啥都做不出來就完了，第三次作業課下修改空間很大，希望補給站的時候能過吧。
對待oo，心臟撒撒給油！
物件導向第二節
coding utf 8 定義乙個列表的操作類 listinfo 包括的方法 1 列表元素新增 add key keyname keyname 字串或者整數型別 2 列表元素取值 get key num num 整數型別 3 列表合併 update list list list 列表型別 4 刪除並...
第二章 物件導向
1 資料型別 簡單資料型別 byte short int long float double char bool 組合資料型別 struct enum class 值型別 內部資料變化不改變外部資料 struct int float 引用型別 內部資料變化改變外部資料 陣列 指標 class 2 變...
物件導向第二天 物件
一 類的定義 1.對一類事物的抽象 將事物中的相同屬性抽象成文乙個類 同一類事物必須具有相同屬性。2 屬性和資料 如 姓名 劉娜，其中姓為屬性，劉娜為資料 相同屬性的便可看作一類事物，但同一類的不同物件可以具有不同的屬性。比如，劉娜這個物件有個頭髮顏色屬性，但是李江權沒有頭髮，故李江權沒有頭髮顏色這...