第五次作業：多線程電梯

?作業內容：相比于前兩次電梯作業，本次電梯作業新的變化是多電梯運行。要想實現功能，便需要學會使用多線程機制，使三部電梯保持相互獨立的對分配的請求進行處理。電梯能夠處理捎帶，且調度時采用運動量均衡策略去響應樓層請求。

類圖：

度量圖：

?

bug分析：存在兩個bug。在多線程電梯的調度過程中，經過一系列的調度操作后，會出現電梯運動量疊加的錯誤，原因在于在運動量進行更新時的條件分支判斷上存在漏洞，在部分情況下會對于同時響應完成的請求進行重復計數，導致整體運動量計算錯誤。另外一點同樣是由于代碼邏輯層次的復雜性而導致的，在對于電梯判斷捎帶請求的分支中存在著FR后對ER的捎帶判斷漏洞。

?

分析評價：從度量圖中，可以明顯的看出電梯對于入隊請求的處理的方法中，分支判斷條件太多，使得代碼復雜性上升，不利于維護。這也是由于設計上的缺陷導致，不能很有效的將分配機制完善以及其他一些機制進行合并，導致代碼復雜性上升并且代碼數量也較多。

第六次作業：IFTTT

作業內容：本次作業是實現一個監控程序，針對于給定范圍內的文件屬性的變化，通過預先設定的觸發器的反應從而執行相應操作。監控的范圍限定為一顆目錄樹。

然而，在本次作業中，由于時間安排上的不合理以及對于代碼的理解還不夠深入，導致未在規定時間內完成。在面對這種文件的監控時，并不能很好的實現對文件屬性的掃描、監控。另外，由于個人原因導致的思考設計上的時間消耗過大，并存在部分不合理的設計，從而使得無法正常實現題目所要求的具體功能。

?

第七次作業：多線程出租車

作業內容：本次作業模擬出租車的乘客呼叫與應答系統，開發相應的程序，繼續訓練線程安全設計方法，同時應用課堂所講授的面向對象分析方法和設計原則來開展分析和設計。

類圖：

?

?

?

度量屬性：

?

?

?bug分析：bug一個。在乘客發出請求后的3s內，應該對所有進入乘客請求服務區間的空閑車輛進行標記，即搶單，但在此期間，若已進行搶單的出租車響應了另一請求并執行，應當對其狀態進行更新，以防止出現同時占用同一輛車的情況。然而，在代碼中，并未對該種情況進行處理，導致有時會出現程序輸出錯誤的情況。

分析設計：在這次作業中，主要考察的是課上所講的SOLID設計原則以及各種設計的注意事項，即對代碼的設計、代碼風格的考察。

在本次設計中，層次化抽象原則體現在將本次出租車問題抽象成為調度器類、地圖類、出租車類、請求類、請求隊列類。而各個類之間的方法均衡、分配上還是略有欠缺，部分方法的長度略微大。并且，部分分支的判斷條件的部分使得代碼邏輯更難被讀懂。

?

心得體會

這一單元的三次作業，難度都十分的大，都是對于多線程的設計與調試。由于課程中后期的代碼對于各個類以及類中方法的嚴密、均衡要求升高，因此，在真正開始作業前，還是應當多花時間去對問題進行細致的分析，并考慮各種可能出現的情況以及哪些情況的判斷或功能的實現能夠進行整合，以此避免bug的出現并使得代碼更為簡潔。否則，將會出現由于設計上的漏洞而不得不耗費大量時間重新設計的情況，致使時間被浪費。除此之外，和同學的交流還是十分重要的，因為對于一個人來說，作業設計上的一些要求容易出現理解上的偏差，如果能多與同學進行交流，不僅能很好的發現、修改理解上存在的問題，也能了解到其他人的設計方案，并將其與自己的設計方案進行相互對照，找出自己設計上的不足，從而在之后的作業中加以改進。

轉載于:https://www.cnblogs.com/98-0901/p/8978136.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的OO第二次作业总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。