本單元的作業內容主要為通過多執行緒調控來實現電梯排程。相較於上一單元，本單元的重點在於保證多執行緒的安全性以及遵循設計的solid原則來設計程式。整體來看，本單元作業的完成情況比上一單元要好，沒有進行大的重構，強測互測也未出現bug，這點是值得肯定的。不足之處還是在於排程策略的優化上沒有下足功夫，導致第二次作業的效能分不理想；沒有很好地遵循solid的設計原則，有些類設計的不好。
從多執行緒設計角度採取了最普通的生產者-消費者模式，這個沒什麼特別要說的。捎帶策略全程採用als。對於電梯的執行則採取了有限狀態機的想法，提取電梯5種狀態：
status0：電梯初始狀態
status1：電梯上行
status2：電梯下行
status3：電梯停靠且有人進出電梯（電梯門需要開、關）
status4：請求全部完成，電梯結束執行
通過實現這五種狀態之間的轉換來實現電梯執行緒。下面具體從每一次作業來看設計策略。
第一次作業整體設計比較簡單，只需要乙個生產者執行緒，乙個充當請求佇列的排程器（實際上沒有排程功能），以及乙個電梯執行緒。電梯的執行策略是，如果電梯內有請求，則優先處理電梯內請求；否則則接收電梯外最早到達的請求並執行，如果沒有請求，則電梯停在最後完成請求的樓層不變。
第二次作業相較於第一次作業，增加了電梯的數量，且電梯有搭乘上限，這次作業的排程器就需要起到排程的作用了。因為沒有想到較好的排程策略，就簡單暴力地將接收到的請求平分給所有電梯，這樣由於無法有效的捎帶，導致效能下降許多，如果將平分改為自由競爭同乙個請求佇列，效能應該會有所上公升。
第三次作業相較於第二次作業，增加了不同型別的電梯，且由於不同型別電梯所能到達的樓層不同，中間需要換乘。由於第三次作業效能的考核增加了每個乘客需要等待的時間，而無意義的換乘會大大增加等待時間。因此本次作業的排程器對請求進行了分離，將不需要換乘的請求分配到對應型別的電梯裡，由該型別的所有電梯進行自由競爭。需要換乘的請求則在固定的層數換乘，方便排程。這次作業的效能分較第二次有很大提公升。
第三次作業的基本架構仍是生產者-消費者模式，在三次作業的迭代過程中，對電梯類的擴充套件非常大，每次都會為電梯類增加新的屬性，這樣是沒有遵循srp以及ocp原則的。應該將電梯類更加細分，將一些具體的操作獨立成類，減輕電梯類的負擔。
分析三次作業的類圖不難看出，程式的整體架構並沒有發生大的改變，前兩次作業在架構上甚至完全相同。但是在分析類以及各個方法的複雜度後就不難發現，由於電梯類內包含電梯狀態變化的有限狀態機，電梯類的部分方法基本圈複雜度很高，且隨著電梯要求的增高，電梯內的方法也越來越多。之前在擴充套件性分析中也提到，這樣是有悖於solid原則的設計。應當將電梯類的功能細分為多個類，使電梯類不那麼冗雜。
本單元作業未出現bug。在與同學的交流中發現，這位同學在第三次作業中將三種電梯分別成類，並在屬性中相互包含，這使得執行緒執行時發生死鎖。相比較效能還是更應該優先考慮正確性。
本單元相比較上一單元而言，在迭代開發上感覺沒有那麼困難了。本單元開始第一次作業的時候是感覺最難的時候，因為對於多執行緒的理解不夠明白，電梯的排程也不太會實現。後兩次作業相較於第一次作業，心理壓力明顯小了很多。
比較幸運的是，儘管電梯寫的過於複雜，在測試中也沒有出現bug。
本單元主要收穫是：了解了多執行緒的安全問題以及程式設計的原則（儘管未能很好的體現在作業上）
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...
OO第二單元總結
第二單元總結 第一次作業 思路與反思 uml類圖 度量分析 耦合度 第二次作業 思路 第二次作業與第一次的迭代在於電梯增加 人數限制 樓層改變，我依舊用的look演算法，在第一次作業的基礎上修改細節即可，多部電梯要求實現執行緒安全，由於我使用的look演算法，電梯盲目執行，沒有更高階的排程，只需要在...