寫在最前：

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

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

正文：

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

指導(dǎo)書閱讀

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

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

類的構(gòu)建及相互之間的關(guān)系

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

請求類是信息傳輸?shù)臄?shù)據(jù)包，該類作為信息單位來承擔(dān)類與類之間交換的責(zé)任。電梯由實際狀態(tài)和電路兩部分組成。樓梯有獲取上下行請求的需求。電梯與樓層將請求發(fā)送至請求隊列，調(diào)度器獲取請求對電梯進行調(diào)度。

關(guān)鍵的問題是類與類之間如何交互？

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

再結(jié)合需求分析，我采取了如下的類的結(jié)構(gòu)關(guān)系：

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

代碼編寫

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。