第一次作業：套用生產者消費者模式。電梯作為乙個單獨執行緒，是消費者。輸入執行緒是生產者。全域性只有乙個任務佇列的共享物件。
第二次作業：採用生產者消費者模式。耦合比較亂的地方：電梯作為乙個單獨執行緒，同時肩負起排程器和電梯的角色。
第三次作業：採用類似於流水線的模式（其實還是生產者消費者模式，不過就是一環套一環）
∶輸入執行緒讀取輸入，放入一級任務佇列。計算器執行緒從前面任務佇列取出任務，根據電梯停靠樓層等資訊，對任務進行拆分，放入二級任務佇列。分發器執行緒從前面任務佇列取出任務，決定該任務是否應該分發出去，以及應該分發給哪乙個電梯。每個電梯執行緒對應於乙個任務佇列，其之後的結構類似於第二次作業的結構。整體上還是靜態排程，沒有根據當前電梯的狀態動態分配任務。本來以為這種多重依賴的結構會比較慢，結果執行效果也還可以。
總得來說，這三次作業以《物件導向∶從重構到重寫》為基本指導思想，充分發揚了艱苦奮鬥，能吃苦能熬夜的精神，將生產者消費者模式一用到底，完成了三次**的從0到1。架構太辣雞，重構？重構是解決不了問題的，勇敢的人直接重寫。
第一次作業，
第二次作業
採取同樣的設計模式：生產者消費者模式。
uml圖基本相同：
類複雜度分析：
方法複雜度分析，只列出了部分可以反應問題的：
可以看出電梯內耦合排程器，甚至共享物件還承擔了部分排程的邏輯，這其實是很不合理的。導致共享物件有幾個方法，電梯的幾個方法複雜度非常高。在第三次作業中，對電梯**進行了部分重構，但效果還是不盡人意。講電梯執行邏輯和排程邏輯解耦才是王道。但是在這三次作業中並沒有實現。
第三次作業
uml圖：流水線式架構，為了使主要結構看起來更清晰，省略了request類（對personrequest的封裝類，主要用於把乙個請求分解成兩個請求）。
有request類時：
類複雜度
主要方法複雜度
只列出反應一定問題的：
可以看出電梯類的複雜度異常的高，也就是電梯和其自身排程器沒有實現解耦，就算多次重構，其複雜度也高居不下。而與電梯相關聯的共享物件也承擔了一部分的排程邏輯。複雜度也較高。應該講該共享物件和排程邏輯封裝成乙個新類。
靠著手寫評測機強測互測沒有被炸點
第三次作業自測出的bugs：
cpu超時。
如果不是開評測機時cpu占用太高，根本不會注意到這個bug。問題在於分發器執行緒是個輪詢執行緒，而沒有用到wait，notify。
執行緒同步。
在某人還沒有出電梯時，就通知接這個人的電梯該接了。問題在於」電梯關門這個動作「和」通知下乙個電梯這個人可以接這個動作「的先後次序。
先每人掛4個評測機跑2000個測試點再說
說一下測試點生成的幾個策略：
完全隨機。力求模擬測評機（並沒有做到）
。完全隨機的測試資料的生成，一般會使得每條請求比較分散，如果有死鎖的話可能（」可能「兩個字就意味著我要開始瞎說了）
會比較容易測出來。
乙個小時間段集中生成測試點。比如：0.1時刻生成40條請求。比較考驗執行緒安全。每乙個執行緒瞬時處理的任務都變多，如果同步沒做好，可能會在這部分炸點。（實際效果上，集中式生成要比完全隨機生成更容易發現bug）
看了強測的測試用例，發現還有一種情況沒注意到，多個時間點集中生成測試樣例。比如0.0時刻輸入10條請求，30.0時刻再輸入15條請求。看得出這應該是精心處理過的樣例，專門用來炸一些**的中止電梯的邏輯。
還有針對**覆蓋率等度量來構造資料集。哈~ 這個沒用過，還在學習中。。
這次苟進a組的經歷讓我有了」原來這就是強者的世界「這樣的感嘆。個人覺得互測的意義其實還是提供了這樣乙個原始碼分析，技術交流的機會，看大佬們的**真的能學到很多東西。刀人其實都是次要的。所以在保證正確性的基礎上，努力提高強測成績，爭取互測時可以看到大佬原始碼才是進步的最快方法。（是不是可以考慮互測結束後，每個房間開放一段時間的聊天室功能
為了能順利苟進a組看到大佬們的**，評測機這個東西還是要經常寫，不然心理不踏實。不能因為一些小錯讓強測炸點。不值得。
關於**可擴充套件性的一些分析和感悟：
對比自己**和大佬**，發現自己**可擴充套件性差的幾點原因
對電梯的建模有數字硬編碼的問題
事實上初始樓層，上行時間，下行時間，載客量，停靠時間，開關門時間這些靜態資訊都應該作為電梯的基本引數，便於統一建模。
電梯執行邏輯和排程策略耦合在一起
當前樓層，當前電梯狀態，當前任務佇列等動態資訊應該來讓排程器來管理。這樣便實現了電梯和電梯排程器的解耦，從而也允許了電梯可以採用不同的排程策略。類似於strategy的設計模式∶排程器定義統一介面，不同的排程器具體實現。
最開始寫**時沒有考慮可擴充套件性是根本原因
還在正確性邊緣掙扎的菜雞，把**寫完後才會想到可擴充套件性這一出。剛寫完**時的心理活動：「我怎麼這麼牛b，這架構完美無敵」；下一次作業看自己上次作業**時的心理活動：「這寫的倒是個**，這也太辣雞了，自己都不想看」；互測看到大佬的**時的心理活動：「這才是物件導向程式設計啊！這可擴充套件性也太高了吧」。
看了很多design pattern，但不會靈活運用
很多pattern就是看一眼覺得大概可以用，但具體實現又覺得情況不怎麼一樣。互測看過大佬**才知道，「奧~ 這個pattern要這麼寫啊~「。所以三次作業最後都只用到了消費者生產者這一種模式。同組大佬將單例模式（輸入輸出全域性排程器的管理），strategy模式（不同電梯具體採用不同的排程演算法），composite模式（實現對任務類的包裝，將一條任務遞迴得拆分成多個任務鏈）用的出神入化。。（可能還有沒看出來的設計模式）
個人**還是有一定可復用性（強行扯皮）
可復用也不一定是在最初就猜到之後**都需要擴充套件，進而設計好介面或者將對應部分引數化。也可以是前一次設計構成下一次設計的乙個子模組，而下一次的主邏輯主架構重寫。前者就像是主框架非常棒，擴充套件時就換換零件就可以了，是零件適應框架。後者就像是零件做的還可以，擴充套件時盡量讓新的框架能用到舊零件。是框架適應零件。前者是大佬的**，後者是我的**。
OO第二次部落格作業
從第4次作業開始，就進入了多執行緒程式設計的環節。我個人對於多執行緒的理解就是在乙個程式在執行時有多個執行流，能夠實現多個執行緒併發執行的技術。由於能在同一時間內執行多個執行緒，因而能夠提公升計算機的整體處理效能。第五次作業分析 由於第五次作業是我第一次接觸到多執行緒程式設計，因此這次作業對於我來說...
OO第二次部落格作業
第五次作業和第六次作業因為一些個人原因被判了無效所以這裡就不拿出來分析了 捂臉 第七次作業 設計乙個簡單的計程車排程系統 類圖 度量分析 其實在剛看到指導書的時候，覺得排程規則十分複雜。週日看了一下午指導書之後才大概想到一點思路，接著就開始了一步步嘗試。其實這次作業的目標十分明確，每個執行緒的任務很...
OO第二次部落格作業
在多執行緒的海洋裡遨遊了三周後，同學們又有了這難得的乙個月一次的oo部落格 休息 時間。多執行緒的各種 玄學 問題可是給我帶來了不少困擾和麻煩。而且這三次作業的共性特點就是特別難debug，不僅是難以給自己debug，給別人debug也不容易。就趁這個時間來回顧下這三周的時光吧！1.簡述 經過了傻瓜...