第一次作業：
1.設計策略
程式採用生產者-消費者模式，一共有兩個執行緒，乙個是主線程，主要負責輸入；另乙個是電梯執行緒，用來處理請求。此外，程式還有乙個核心——排程器，內建請求佇列和排程函式，相當於托盤。主線程不斷將請求輸入到排程器中，而電梯執行緒每完成「上樓-開門-出人-進人-關門」的一次迴圈就從呼叫一次排程器的排程函式，以獲得下一步的動作。如果排程器中的隊列為空，則wait()，直到被喚醒。
排程器採用的是look演算法，電梯的執行方向一般不改變，除非在該方向上已經沒有請求。而排程函式的作用就是在電梯執行方向上尋找需要最近停靠的樓層，並將相關的出入乘客的資訊包裝起來傳遞給電梯執行緒。在這個過程中排程器需要獲得電梯的樓層的狀態，所以兩者採用觀察者模式，排程器為觀察者，電梯為被觀察者。
2.程式結構
類圖：
**行數：
第二次作業：
1.設計策略
對於電梯容量限制的問題，只需稍稍修改一下排程器中的排程函式，在尋找樓層時考慮電梯的容量，出人量與進人量的差不能超過電梯的剩餘容量，同時當電梯人數滿時跳過進人請求，只考慮出人請求。
2.程式結構
類圖：
**行數：
第三次作業：
1.設計策略
第三次作業同樣也只需要在第二次作業上做一些迭代。最主要的修改是增加了主排程器，負責對各個電梯的排程器進行控制。主排程器的核心部分是對乘客請求進行處理，判斷是否換乘，如果不換乘需要哪種電梯，如果換乘則需要哪兩種電梯配合。同時主排程器也內建請求佇列，可以接收主線程的乘客請求，同時也可以接收來自電梯的需要換乘的乘客請求，然後將佇列中的請求送入對應電梯的排程器中。
2.程式結構
類圖：
**行數：
可擴充套件性分析：
srp——單一職責原則
總體而言，每乙個類的職責都是比較明確單一的。主類負責相關輸入，排程器負責電梯執行策略，電梯負責相關輸出。但是在第三次作業中，主類不僅負責輸入，同時也負責電梯的初始化及後續的增加電梯請求的處理，這一點違反了srp。
ocp——開閉原則
ocp主要體現在作業的迭代過程。在第一次作業到第二次作業的迭代中，為排程器中的佇列類新增新的限制人數的方法，即達到電梯有限容量的效果。但在第二次作業到第三次作業的迭代中，由於一些請求需要換乘電梯，原先排程器中的佇列類的資料儲存方式不能再滿足需要，必須修改相關的域和方法，這點在設計時有些欠缺。
lsp——黎克特制替換原則 &
isp——介面隔離原則
本設計中的主要部分未用到繼承和介面，而是為電梯的構造方法傳入不同的構造引數從而構造不同類別的電梯。從這點來看設計的抽象層次不夠，如果電梯的屬性發生改變就可能需要重構**。
dip——依賴倒置原則
在這一方面仍是抽象層次不夠的問題，應當為電梯、排程器都建立一種介面或抽象類，然後各類電梯和排程器都實現該介面或繼承自該抽象類，增加程式的可擴充套件性。
bug分析：
第一次作業並沒有出現bug，但第二次和第三次作業都出現執行緒無法順利結束的bug。在第二次作業中導致該bug的原因主要是在輸入結束後，如果有電梯執行緒因隊列為空而阻塞，就沒有其他執行緒能夠喚醒該電梯執行緒。而第三次作業是當電梯已滿且處於頂樓或底樓時，排程器的排程函式沒有改變電梯方向，於是進入死迴圈。
感想：
經過了第二單元的學習，我對執行緒安全，執行緒同步的概念有了一定程度的理解，也初步體會到多執行緒程式設計的不確定性所帶來的debug的困難。此外，我也認識了觀察者模式，生產者-消費者模式等設計模式，體會到了優良的設計模式所帶來的優勢。
對於這三次作業，我對自己的設計還比較滿意，兩次迭代都只在前一次作業的基礎上進行功能的擴充套件，但最終的成績卻不太理想，其主要原因還是在評測方面下的功夫太少，在後續的學習中還需繼續努力。
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...
OO第二單元總結
第二單元總結 第一次作業 思路與反思 uml類圖 度量分析 耦合度 第二次作業 思路 第二次作業與第一次的迭代在於電梯增加 人數限制 樓層改變，我依舊用的look演算法，在第一次作業的基礎上修改細節即可，多部電梯要求實現執行緒安全，由於我使用的look演算法，電梯盲目執行，沒有更高階的排程，只需要在...