OO第一次總結

度量分析的工具真的好難搞！到現在我的metrics也無法正常使用，可以建立它的透檢視，但是不能再工程的屬性裡找到它......得，我現在只能展示類關係圖譜（逃）。

oo給我的感覺就像是雨夜登山一般，「登山」本已舉步維艱，大晚上的還漆黑一片，得「邊爬邊摸索」，要是走了面向過程的「歪路」，也難免重頭再來。加之各種條條框框如大雨般傾盆而下，一不小心就弄個「泥濘不堪」，如果不慎落了「無效作業」的大坑，也只能叫苦不迭但無力回天。

嗨，這麼一寫還突然覺得，oo有點意思。

第一次作業是要寫多項式的加減，我的程式的大體結構如下：

其中，main是主類，負責呼叫其他的類，並執行程式；

check類是用來檢測輸入的字串是否合法的，在這裡主要使用了正規表示式來判斷；

operation類是用來實現多項式加減的，主要是乙個大迴圈，乙個字元乙個字元向後讀。

第一次作業的公測錯了兩個點，互測沒出問題，第乙個是爆棧，原因是我的正規表示式就是乙個長串來匹配整個的輸入，導致在最大長度的輸入情況下程式出了問題。把輸入的幾十個多項式按花括號拆開，再進行正則匹配即可解決。

第二個點是沒有考慮-0還是什麼關於正負號的乙個小點，後來仔細閱讀指導書後，大呼之遂心服口服，這很好的提醒了我在以後的作業中要仔細考慮各種情況以及仔細閱讀指導書，勤於思考各種非法的情況。

我的第一次作業的**量比較少，可能勉強算是乙個有點，但第一次寫物件導向的程式，總是有些四不像的感覺，不會使用建構函式，把所有的功能都放在了類的方法中，形似面向過程。

第二次作業是寫乙個服從「傻瓜排程」的電梯，即根據指令的時間順序來控制電梯的運動，我的程式的大體結構如下：

其中，request類是用來處理單條需求的，通過正規表示式判斷指令是否合法，進而判斷指令是哪種型別（fr+up，fr+down，er），然後將指令分解，分別去判斷時間和樓層是否越界。因為考慮到時間可能超過int型的範圍並且會有很多的前導零，我用了乙個迴圈來算時間...

for(int i=0; i) 
}

queue類是用來迴圈讀入指令的，呼叫了request類，對單條指令進行處理，並把它們分別存在對應的陣列中。

elevator類是用來記錄電梯的執行狀態的，包括電梯現在所處的樓層，下乙個樓層，當前時間，下乙個時間，電梯執行時間，執行狀態等。

floor類是用來記錄樓層資訊的，但其實實際操作中我幾乎沒用到它，因為elevator類裡的東西就夠用了。

scheduler類是用來執行電梯排程的，例項化了queue類的物件來讀入指令，也例項化了elevator類的物件來記錄電梯的執行狀態，並設定了一些其他的屬性來模擬電梯的執行。

private
double erbutton = new
double[20];
private
double frupbutton = new
double[20];
private
double frdownbutton = new
double[20];

上面三個按鈕陣列用來模擬電梯裡面和樓層上的按鈕。開始時我想用boolean型的陣列，但是發現那樣只能記錄按鈕的狀態，不能記錄按鈕狀態改變的時間，所以我後來改用double型，記錄每個按鈕被釋放的時間，即這個按鈕在哪乙個時刻可以被再次使用，在這個時刻之前，如果有人發出了需要這個按鈕的指令，則被視為同質指令。

if(queue.requesttypearray[valid] == 1) 
}

拿一段**來說明，比如一條指令的型別為1（fr+up），那麼比較讀入指令的發出時刻與該指令的對應按鈕的釋放時間，就可以判斷這條指令是不是同質（在這之前先判斷是否合法）。這樣就不需要預先知道後面的指令是什麼，簡化了**的複雜度。

如果它不同質，那麼就可以產生乙個對應的輸出，並改變某個按鈕的釋放時間，部分**如下：

if(queue.requesttypearray[valid] == 1)

比如這條指令的型別是1，那麼就將frbutton中對應按鈕的時間設定為elevator.nexttime（即經過計算後的電梯達到下乙個樓層的時間），這樣就可以讓程式不斷的迴圈運作了~

第二次作業的公測我沒有錯測試點，互測錯了乙個，是：輸出如果超過了int範圍並且是小數，那麼我的輸出就會把它的小數部分給省略掉，後來我尋找原因，發現在這個地方：

system.out.print(bigdecimal.valueof(elevator.nexttime));

我為了使輸出不是科學記數法的形式，我用了bigdecimal，但不知為啥這裡會出這樣的么蛾子......

第二次作業我花了很久的時間去思考，主要在想如何去判斷各種同質的狀況，後來經過不斷的摸索，並且有意識地去模擬真實電梯的屬性和方法（在我理解裡的物件導向吧），我選擇用按鈕這個概念來記錄電梯的被觸發不同狀態後的終止時刻，想明白了這個之後再去寫**就順暢了許多。有了這次的經驗，我在寫第三次作業之前花了更多的時間去思考。

第三次作業的電梯是在第二次作業的基礎上考慮「捎帶」這一規則，我本以為只需要小改一下就成，後來在實際操作中我才發現自己錯的離譜......先展示一下程式的大體結構：

其中，除了subscheduler類以外，其他幾個類與第二次作業基本相同，不贅述；

subscheduler是繼承了scheduler父類的子類，說來慚愧，我這次作業幾乎只幹了一件事兒：重寫了scheduler父類的run函式......

因為電梯要捎帶，那麼電梯的執行就不能只是發生在相鄰的兩條指令之間了，因為後面的指令或者時刻靠後的指令完全有可能要先執行，判斷哪些指令要先執行就是最大的難點所在。我先很自然地想到我們使用的電梯是什麼樣的，在運動到某一樓層前，如果接收到這個樓層發出的訊號，如果方向相同便可以停靠，那麼關鍵點有兩個，乙個是位置，乙個是時間。我最初想到的是以時間為主線，直接以0.5s為最小的度量，每過0.5秒記錄電梯的位置和執行狀態，然後去佇列中搜尋有沒有這個時刻或之前發出的同層的指令，後來因為各種考慮放棄之。

於是便選擇了先遍歷一下讀入指令後面的指令，如果這條指令滿足可捎帶的條件，執行之，然後把它從請求佇列中剔除，並改變一些按鈕被釋放的時間以及樓層、到達時刻等屬性，其中一部分大概像下面這樣：

else
if(elevator.condition.equals("up")) 
if(queue.timearray[j] < (elevator.nowtime +extratime)) 
else}}
}

很繁瑣，分了電梯執行的各種狀態以及指令的各種型別來分類討論，這裡把主指令之後的指令存入乙個新的陣列中，而不是直接輸出，因為它後面還可能有比它還要提前執行的指令，所以輸出也變得很繁瑣了......

if(elevator.condition.equals("up"))

我在主請求結束後進行這個輸出的迴圈，大體思路是上面的程式段記錄了每個樓層的停靠狀態，之後遍歷樓層，把有標記的樓層按要求輸出。這是一種以位置為主軸的方法吧。因為一層樓中可能會開若干次門，所以只能建立乙個二維陣列extraorderarray來記錄某層樓的可能出現的若干次開門的請求。

很幸運，第三次作業的公測和互測都沒有出bug，可以說是很振奮人心了。但想到之後要寫多執行緒的電梯，感覺程式難免還是要修改，還是很令人頭大。

這次作業雖然重點只是放在了重寫run函式上，但週六日兩天恰好有事情不能寫oo，結果導致我的周一二三過的相當艱難，通宵數宿，苦不堪言，不堪回首，觸目驚心......想不想得清楚是一方面，更重要的是一些小的細節的改動會牽一髮而動全身，本來想要微調結果不得不大刀闊斧的改一通，其中折磨可想而知。這也讓我吸取到了很寶貴的經驗：一、拖延症害死人，能早點解決的事兒別把它養肥了；二、磨刀不誤砍柴工，在頭腦清醒時先把問題想清楚，方法想完善，必要時可以手寫一下流程框架圖什麼的，這樣說不定就能事半功倍。

總的來說，oo還是讓人收穫頗豐的，別的不說，就是以後得去「搬磚」，基本的程式設計能力還是要有的，毋庸置疑，oo鍛鍊了我的程式設計能力；其次，在思考和對問題的分析上，我可以有意識地用物件導向的思路去思考問題（或許我還並不能正確認識什麼是物件導向），這是一種有趣的思考過程，我總感覺這樣幻想出來的物件還有點可愛......

最後祝大家永不被判無效作業！實在太痛了，也希望以後的oo能公升級一下無效作業的判斷機制吧。

OO第一次總結

OO第一次部落格總結

第一次總結

第一次總結

相關推薦