第二單元總結

1、做業分析

1.多線程設計與控制

我設計的原則是能少創建線程則儘可能不要多創建沒有意義的線程，這樣多線程相關的設計與控制將更加簡潔。關於線程衝突，我主要採用synchronized來進行同步控制，和共享數據相關的方法須要保證其操做原子性的均加上synchronized關鍵字，爲防止電梯等待請求的輪詢。使用wait方法。

2.具體架構

個人電梯總體上採用的是look調度原理，既電梯在樓層間掃描，若能夠調頭，則調頭，如有人要上則上人。第二次做業和第一次做業差異不大，我爲每一個電梯開了一個storage，請求從主線程讀入後幾乎不訪問電梯的狀況將請求放入倉庫。第三次做業較前兩次變更比較大的是須要換乘，我考慮在一、15樓換乘，若電梯沒法知足請求則在此拋出請求給其餘倉庫，此時要增長電梯和其餘電梯、倉庫的交互，須要比較謹慎，在此我採用hashtable容器來存儲電梯與倉庫做爲共享變量。關於結束程序是個比較難以考慮的點，前兩次我都是採用最後放入storage一個特殊的請求，做爲輸入結束的標誌，而第三次因爲換乘請求可能在輸入結束標誌到來後到達，我設計了一個標誌來表示電梯是否可以退出，該標誌可讓電梯跳過裝人環節，當該標誌置位時訪問其餘電梯的狀況，若該標誌均置位則能夠結束線程。

（1）類的度量

下面爲三次做業類的度量：

能夠看到第一次做業中判斷是否要下人和是否須要調頭的方法的複雜度較高，而這些方法幾乎是必須的，看見此次的複雜度控制的比較好，第二次同第一次做業同第一次相似，修改也較少，變化不大，第三次做業方法增長了許多，可是複雜度幾乎沒有大的變化，可見三次做業複雜度控制的比較好。

（2）類圖

三次做業的類圖以下：



三次設計思路相似，類圖也看起來差異不大。很明顯，三次做業在低耦合這一點上作得還不夠好，好比電梯類其實能夠簡單的只負責上下開門一類的，利用一個單獨的控制類來對電梯的行爲進行控制，這樣也不至於致使電梯類的行數太多，電梯只接受控制器的控制，另外還能夠單獨構造一個類來儲存各個電梯的信息，這樣在交互的時候邏輯也比較簡單，而且不容易出錯。

（3）協做圖

因爲低耦合作得很差，因此類比較少，只有main、elevatro、storage三個類，類、線程之間的交互也比較簡單，三次做業的內核都採用上圖所示的方式，電梯每到一個樓層向storage索取請求，若是沒有且知足其餘一些條件則wait，storage每次get到請求便notifyall，交互邏輯簡單，這算是優勢，第三次的結束部分增長了知足結束條件則上下游走，等錢其餘電梯以確認換乘不會增長請求，此處沒有增長wait，固然其實這樣的處理很差，只是爲了寫起來簡答，可是對電梯而言就比較累了。

3.設計評估

（1）性能設計

關於性能，我三次都是再以前的基礎上知足額外功能要求，基本調度採用look算法，好比第二次當請求到來時我會先獲取各電梯線程的狀態，若爲WAITING則放入對應的倉庫，若沒有正在WAITNG的電梯則隨機放入一個倉庫，實現起來比較容易，不涉及電梯信息的交互，分數上還算過得去，算是性價比比較高的寫法。第三次的換乘則不得不添加一些電梯間的交互，大致上請求調度也採起隨機的方式，分數也還過得去。

（2）設計原則（SOLID

SRP單一責任原則

不得不說個人類之間的耦合度一次比一次高，類之間的分工還算明確，但整個做業不過三個類而已，這一點作得很很差。卻是其中的方法分的比較細，從方法的角度來看還算知足單一責任原則，面向過程的意味比較濃。

OCP開放封閉原則

這一點作得通常，每次寫做業仍是主要考慮當次做業的需求，習慣性的修改原有的代碼，可是個人方法劃分比較細，單個方法的獨立性較好，方法與方法之間的耦合度較低，所以修改時每每只涉及到部分方法。

LSP里氏替換原則

做業中未涉及繼承，固然這是很差的。

ISP接口分離原則

寫代碼仍是不習慣設計接口，可能做業的工程量還不算大。

DIP依賴倒置原則

對於一套倉庫和電梯而言，是知足這個原則的，僅僅是在交互時可能發生跨層次交互，總的來說這一點仍是符合的。

（3）可拓展性

寫代碼時沒有意識來實現更好的可擴展性，每每擴展時須要對代碼比較熟悉進行修改，畢竟做業的工程量較小，層次劃分不夠，做業的時間跨度也比較短。固然通過兩次迭代的過程，多少有一些擴展性比較好的地方，特別是第三次，由於第三次電梯的種類比較多，類型差別還算比較大，我採用一個構造方法來實現不一樣的電梯，所以就算新增種類的電梯也可以簡單的增長構造方法的邏輯分支便可。關於線程的交互，好比電梯之間的交互，因爲個人設計原則是儘可能少交互，因此沒有實現一個統一的交互平臺，這是不足的，影響擴展性。

2、BUG分析

1.個人BUG

第三次做業中電梯會在一些極端的狀況出現進入wait以前，條件判斷以後觸發notify，致使wait沒法退出的狀況，在調整了判斷條件，增長了notify的狀況下得以解決。

2.他的BUG

第一次的時候雖然沒有hack成功，可是我發現有個同窗開門用0.4s，關門用0.4s。。。這告訴咱們要認真讀題！！！第二次的時候在互測的最後關頭髮現有個同窗的超載處理有問題，會出現電梯的超載的狀況，但是時間不夠沒能成功提交合法的互測樣例。。。第三次的時候發現有同窗的電梯會卡住，程序沒法退出，應該是退出邏輯沒有寫好。第三次做業經常有不知道爲何非法的構造樣例，真的已經仔細看過互測用例要求了仍是提交不上去，但願從此可以反饋非法緣由。

3.測試相關

我通常會簡單讀一下代碼，若是以爲有問題則想辦法構造樣例，另外我也寫了測評機，隨機生成測試用例，若是有問題則分析問題所在。

3、心得體會

要先作設計再開始動手寫代碼，低耦合高內聚應該深刻人心，設計不該該只是針對做業知足做業要求，還應該考慮設計的「美觀」（儘可能劃分層次，從類入手設計，功能考慮完善），這樣犯錯的機率也更低，效率也更高。此次我瞭解了多線程，是個很神奇的東西。此次還讓我認識到，關於性能分，個人水平仍是追求高性價比比較好，特別是對於一些說不清楚的東西，帶有隨機性的東西。就像咱們的人生，沒必要貪心。