OO的第一次死亡

　　久仰OO大名，老是想着提早作點準備，其實到頭來仍是什麼準備都沒有作，因此這學期就是從零開始的面向對象生活，也所以遇到了不少的問題。

• 第一次做業——多項式加減

　　第一次做業從來是較爲簡單的，可是對於面向對象零基礎的人來講也是有所困惑，到底什麼樣子的代碼纔算是面向對象？初次見識java，徹底體會不到面向對象的思想，於是在代碼編寫中透露出了一股濃濃的面向過程思想，基本就是照着C程序改過來的，勉勉強強寫了個Class上去，然而仍是main方法乾的活多，只在Mult_to_operate類中寫了幾個簡單的操做多項式的方法，而在main方法裏輸入數據，判斷格式。這樣子的代碼根本就是一個C程序的翻版，畢竟本身當時真的就是java零基礎。

　　第一次做業的度量和UML圖:

 

　　因爲是第一次使用正則，理解的不是很透徹，所以發生了正則爆棧的問題，可是爲時已晚，也沒有想到解決辦法，只有使用try-catch大法來如實報告本身的錯誤，致使最後一個壓力測試的測試點沒過。對於格式的處理，本想使用狀態機來判斷，因而將C程序的狀態機複製過來，可是立馬發現了很明顯的錯誤，沒有對最後一位符號進行判斷。這也是我在互測時尋找別人BUG的方法，由於我遇到的那我的就是使用狀態機來判斷格式的正確與否，所以着重考慮了式子的最後一位，最終發現了兩個BUG+一個數組越界的Crash。在互測階段，被報告了一個bug，即多個前導0，而我在正則表達式中只匹配了一個0，這的確是疏忽大意了。

• 第二次做業——傻瓜式電梯

　　在作此次做業時，已經初步瞭解了面向對象的思想，在做業中也使用了五個類，多個方法去實現，其實對於傻瓜式電梯，若是可以明白電梯運行的原理，就會變的很是簡單，不管是樓層請求仍是電梯內請求，都是爲了到達那一層，所以在運行時只須要考慮電梯要上行至要求的樓層仍是下行至要求的樓層就能夠了。可是在此次做業中出現了致命的錯誤，也是極爲簡單的錯誤——輸入的指令不正確時忘記輸出ERROR，其實若是這裏沒出問題的話公測確定是全過了，互測階段被報的BUG也是這個緣由。此次做業其實很是簡單，因爲不須要考慮捎帶，徹底沒有本身一開始因此爲的那麼困難，而本身在互測階段也沒有可以發現別人的BUG，畢竟此次做業的邏輯很簡單。

　　本次做業的UML圖和度量：

　

　　在此次做業中，elevator的內容過少，只有設置樓層和讀取樓層，而requestline幾乎就是將request重複了一遍，而Floor類是幾乎沒有什麼用，就把他當作主類來運行了，而絕大部分的工做都是由Scheduler類實現，它乾的活最多，每一個類的方法分佈很是不均勻。

• 第三次做業——可調度電梯

　　可調度電梯相比於傻瓜式電梯，也只是多了一個條件，就是可以捎帶，而其他的運行仍是和傻瓜式電梯同樣。

　　我我的的作法就是首先將當前指令加入到一個小「隊列」中，而後對當前指令進行判斷是否存在能捎帶的指令，若是可以捎帶，就把可以捎帶的指令往小「隊列」中添加，判斷了一遍以後再從當前指令開始再次判斷一次，由於在第一遍掃描過程當中，最終完成的指令可能已經發生了改變，於是可能有新的指令能被最終指令捎帶上，經過這種判斷方式，就可以生成一條小「隊列」，而後開始運行這條小「隊列」，小隊列運行完畢後再從指令中尋找到下一條沒有運行過的指令，開始建立新的小「隊列」。

　　本次做業的UML圖和度量圖以下：

　　

　

　　此次的代碼因爲基本是照搬上次的代碼，致使在修改時，承接了上次的思想，於是致使Scheduler類更加臃腫了，因爲判斷失誤，而最後時間不充足，沒有充足的時間去改正方法，致使出現了兩三個代碼類似度極高的方法，非常臃腫，其實能夠簡化不少的代碼。

　　可是本身在最初失蹤沒有正確理解到捎帶的概念，到底何時可以捎帶，何時不能捎帶，上行捎帶和下行捎帶的區別，這些問題本身的都沒有弄清楚，最終在代碼中出現了大量的BUG，通過不斷的調試，勉強經過了全部的公測點，可是本身也意識到在某個地方仍然存在着錯誤，卻是對於稍長一點的測試數據就會出現問題，但已經沒有時間去調整了，只有在後來才能進行調整，互測階段被找到的BUG也是因爲稍長的指令而出現的問題，初步定位在下行捎帶的位置，由於本身在最開始誤認爲上行捎帶和下行捎帶是同樣的。

　　互測階段所獲得的代碼又是一個大佬級別，上行下行，基本都測試了，可是仍是挑不出任何錯誤。

 

　　心得體會：

　　在OO課程的學習中，逐漸領會到了面向對象的思想，並可以將其運用到代碼撰寫中，雖然仍是比較初步的思想，並無深刻，可是經過課程的逐步學習，已經逐漸掌握。其實對於java這門語言，語法基本不用學習，重要的就是面向對象的思想，不然徹底就能夠把java當作另類的C程序，那麼這樣子的java就失去了意義。

　　在撰寫代碼時，有一個清晰的思路極爲重要，若是可以首先就將思路理清楚，知道首先幹什麼，而後再去幹什麼，同時要弄清楚原理，不能看的迷迷糊糊就急急忙忙的開始寫，這樣只會在後來的測試中發現更多的BUG，就好比第三次做業，若是可以好好的看清楚要求，在開關門時刻不進行捎帶請求，那麼後面我所遇到的不少問題都不會出現。在調整程序的過程當中也要注意對於代碼的改動所產生的其餘影響，不能出現把這個BUG修復了，上一個修復了的BUG又冒出來的狀況，這樣子作徹底是就是得不償失。

　　測試程序時，首先要了解程序的運行機制，在每一個關鍵區域都考慮一下是否會存在錯誤，如數組的邊界等。讀懂本身的代碼容易，讀懂別人的代碼難，可是隻要用心去看，老是可以大體瞭解到別人的思路，順着別人的思路去思考，去測試，這樣纔有可能發現BUG，而一味的靠猜，靠試，是很難發現本身或者對方的錯誤的。