寫在最前：

我我我我我我靠，以后再也不再ddl截止前1小時調試程序了！之前在DDL前1小時修改程序，當我改完后，我想著，再把之前的測試樣例跑一遍，如果都對就OK了。就在這時，問題出現了，我之前正確的測試樣例變成錯誤了。我心頭一驚，想著會不會是哪里改錯了。但是更恐怖的事情還在后面，我打開之后，我的輸出是——沒有輸出！無可奈何之下，我先在本地測了一下，發現是正確的。同樣的樣例不止一個。很無奈之下，我又交了一次。更更恐怖的事情出現了，剛才錯的對了！正當我驚喜之余，發現更更更恐怖的事情，剛才對的又錯了。重復好幾次，輸出為空就像薛定諤的貓一樣，隨機出現。

我只能安慰自己，這大概是評測機的問題吧，揮手向DDL告別。

正文：

此次作業我們目標是實現一個單部電梯運行控制系統，電梯調度策略為先來先服務(FAFS)，與真實生活相比較為簡單。接下來我將簡單回顧下自己該項目的完成過程，力求再進行項目設計與實現時能夠更加合理。

指導書閱讀

在項目開發之前，指導書的閱讀總是重中之重。在此次項目開發中，指導書的閱讀同樣占用了不短的時間——一個晚上的時間。

由于指導書本身較長，單通讀一遍所花時間已經很長。往往發生的情況是讀了后面的忘了前面的，必須要長時間閱讀才能對所需完成的項目在任務目標和輸入輸出格式上有一個基本的了解。此次閱讀中我采用了一種方法，感覺效果不錯，那就是——筆記！在閱讀指導書的同時將要求按照自己的理解進行重新編寫，一方面幫助自己更好地理解項目，同時也大大縮減了書寫readme的時間。(更為具體的閱讀指導書的思路就暫時沒有了)

類的構建及相互之間的關系

在進行電梯系統設計時，由于需要將任務分割為多個對象進行分別設計，那這些不同的對象之間如何交互便顯得尤為重要。此次電梯控制系統需要設計的主要類有五種，電梯，樓層，調度器，請求隊列，請求。在設計之前，首先需要明確五個類各自的功能。

請求類是信息傳輸的數據包，該類作為信息單位來承擔類與類之間交換的責任。電梯由實際狀態和電路兩部分組成。樓梯有獲取上下行請求的需求。電梯與樓層將請求發送至請求隊列，調度器獲取請求對電梯進行調度。

關鍵的問題是類與類之間如何交互？

我們當然可以將交互信息放在主函數中，但是這樣在該系統中主函數便是一個信息傳遞的中心，與我們希望實現一個半封閉的電梯系統背道而馳。我們更希望類本身之間能夠進行相互訪問。想要相互訪問，我能想到的方法便是讓某些類的對象引用作為屬性存在于其他類中。

再結合需求分析，我采取了如下的類的結構關系：

調度器、樓層、電梯共享一個實例化的請求隊列類，同時電梯也作為調度器的一個屬性存在。采用這種方式實現類與類之間的交互

代碼編寫

當我回顧編寫代碼的過程時，總覺得有些哭笑不得。在構思清楚類與類之后，花費一晚上時間才構建并調試好各個類和一個輸入的框架，實現了能夠將正確的請求列隊的操作。當我代碼碼到這一步時，從來不曾想過該如何實現電梯的調度。而真正開始思考并編寫核心——電梯的運轉邏輯，竟然只花了前者一半的時間。這樣的時間差真讓人無可奈何。

總結

以上是生活随笔為你收集整理的java第二部分项目_Java_第二次作业：项目构思与实现的全部內容，希望文章能夠幫你解決所遇到的問題。

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