OO第二單元總結——多線程電梯

設計策略分析

電梯1：

任務：單部多線程傻瓜調度（FAFS）電梯

實現：3個線程，單例模式

Thread1:主線程

Thread2:輸入處理線程

Thread3:電梯運行模擬線程

構建一個共享對象，用於put、get請求，該對象全局惟一，被Thread2和Thread3共同擁有，給該對象的方法加同步鎖synchronized，以確保請求隊列的安全。

經過wait、notify，使電梯和輸入處理線程交替進入共享對象的臨界區執行。

電梯模擬行爲：從隊列取一個請求，獲取其fromFloor、toFloor、personId，一次只進入一個請求、將該請求完成後再進入臨界區獲取新的請求，當取得請求爲null時，表示沒有請求了，結束電梯線程。

 

電梯2：

任務：單部多線程可捎帶調度（ALS）電梯

實現：整體架構與第一次沒有太大變化，只是改了調度器的調度方法和電梯相應的請求處理行爲

調度器主要method：

mainGet()：返回請求隊列第一個元素，傳給電梯，做爲其主請求；

passGet()：傳入電梯的當前樓層和其主請求，返回可捎帶請求隊列；

nobody_passGet()：傳入電梯當前樓層和其主請求的fromFloor，返回電梯接主請求的途中可捎帶請求（至關於一個小優化）；

電梯requestHandler()：電梯爲空時，與調度器交互得到主請求，而後從當前樓層出發前往主請求的fromFloor，途中在每一層調用nobody_passGet()，在主請求進入電梯後，執行主請求，在每一層調用passGet()，而且在每一層進行判斷，調整主請求爲電梯乘客隊列中的passger.get(0)。

 

電梯3：

任務：多部多線程智能（SS）調度電梯

實現：電梯架構依然沒有太大變化，仍然是單例模式。

對於每一個電梯，採起ALS策略。

給PersonRequest添加一個bool變量canIn，true表明活躍（可進入電梯），flase表明休眠（暫時不可進入電梯），其做用爲：因爲特殊請求會換乘，所以調度器會將這類請求進行拆分紅兩條請求，前請求進入電梯，並將後請求的canIn設爲false並留在請求隊列，在前請求到達換乘樓層並出電梯後，激活後請求（即將後請求的canIn設爲true）。

---

OO度量

電梯1：

UML

Complexity metrics

 

電梯2：

UML

Complexity metrics

 

電梯3：

UML

Complexity metrics

 

度量分析：

前兩次做業的複雜度都較低，第三次做業中調度器類的總循環複雜度和平均循環複雜度都較高，用於拆分請求的方法複雜度也很高，主要緣由是該method中用了大量的多重嵌套的條件控制語句和循環。

設計原則分析：

因爲沒有使用接口，只繼承了thread類，此處不談LSP和ISP；

基本上三次做業基本符合SRP原則，每一個類或方法都有一個大體明確的職責，但其實還能進一步明確各方法的職責；

在第一次電梯的基礎上，只需擴展調度器的調度方法，便可實現ALS調度，可見符合OCP原則；

在第三次做業中，電梯類和調度器類的交互是依賴於抽象類實現的，並無依賴於電梯類的具體對象進行交互，於是知足DIP原則。

---

分析本身程序bug

前兩次做業沒有bug，可是第三次做業在強測中幾乎爆零，這個bug是因爲思惟定式，每部電梯在每層樓都和調度器進行了交互，於是致使電梯在不能停靠的樓層進行了開關門動做，增長一條判斷語句便可修復該bug。

---

分析他人程序bug

很顯然，本單元因爲涉及到了多線程，又因爲輸入的定時投放問題，傳統的hack策略已經不奏效了，因此我使用評測腳原本實現定時投放，並對其結果進行自動化測試。

第一單元的做業，測試數據很容易構造，輸出只有一個表達式，對於不太長的數據，基本能夠經過肉眼判斷其正確性，但電梯做業的輸出是十分長的，尤爲是第三次做業各電梯的輸出相互交叉，難度更大。另外，電梯做業的bug可能很難復現，有時候評測機也會誤判。

---

心得體會

本單元設計到了多線程，而多線程很重要的一點就是其線程安全，也是多線程的難點之一，經過對共享對象的方法加同步鎖來實現臨界區互斥，利用wait()、notifyAll()來調節線程進進入臨界區的順序，固然還有更多的互斥機制，能夠彌補synchronized的一些缺點，例如高併發下會損失效率。這三次做業我都採用了單例模式，這使得個人三次做業架構基本相同。在設計層面上，儘可能符合SOLID原則，可加強代碼的拓展性、複用性。這三次做業，不只使我接觸了多線程，也讓我對OO設計層面有了更深的理解。

---

 

最後就是，針對我第三次電梯做業大翻車的狀況，告誡本身，千萬不要面向數據編程！！！