OO第一階段做業總結

         對於OO這門課，學長學姐偶爾提起，你們都略有耳聞，可是並無將其和計組相提並論。所以，在剛開始接觸的時候，並不認爲其會比計組難到哪裏去，然而事實證實，仍是不要想固然去判斷，以及不提早學好JAVA對於OO這門課會下降不少的生存率。

代碼度量分析程序結構：

       第一次做業

       Metric度量分析：

             在度量分析中，能夠看到第一行是紅色標註的，這反映的是一個模塊的複雜程度，而第三行反應的是各種的嵌套深度。從中不難看出，我所撰寫的某個方法過於複雜，這是因爲我將正則表達式的匹配加之對其是否正確的判斷以及最後的輸出功能都放在了這個方法中，所以出現了這個方法過於複雜的狀況。從根本上來講這是因爲第一次接觸java語言，對於面向對象的思想仍是不夠理解，本質上仍是撰寫了一個偏面向過程的程序。所以，應當將每一個功能細化和分開，這是十分重要的。

 

       類圖：

       發現的bug、設計思路：

      第一次做業我自認爲是測試得比較詳盡的，然而卻忽略了指導書上提到的一個點，致使了三個測試點錯誤，那就是當係數爲0時，不打印這對數。我當時並無仔細去看指導書，對於這點要求是真的沒有看清楚，這讓我十分懊惱，也讓我懂得了指導書是很重要的一個東西（還有readme）。慚愧的是，此次做業中還有一個bug沒有被公測和互測測出，從而致使了第二次做業的失誤。   

      在設計上，我將正確匹配到的數字存入一個大數組，而後用dividenum()方法將其分割爲係數和指數，而後進行同指數合併並計算排序，思路簡單，可是實現複雜。而且正則表達式的匹配功能並不完善，判斷過於複雜和繁瑣，以及對於數據的邊界狀況並無進行很好的測試。

 

       第二次做業

        Metric度量分析：

       

         在第二次做業中，一樣出現了方法過於複雜的狀況，也就是第一行所標註的get_list()方法，我將讀取字符串，處理字符串，存儲正確的字符串這三個功能，都放進了這一個方法中實現，所以過於複雜是理所應當的，同時還出現了第二行所標註的問題：參數過多。因爲要實現這巨大的功能，所以大量的參數和變量是必不可少的，這就顯得程序的這個方法模塊很膨脹，可讀性很是低，而且致使我在後來debug時十分困難，連本身都記不清楚這些參數變量表明的含義，還得花時間去回憶和從新理解，得不償失。可是此次的做業更「OO」了一點，也就是更加的面向對象化了，對這種思想有了更進一步的理解。

        類圖

       發現的bug、設計思路：

       在我認爲第二次做業已經測試得足夠完善時，公測結果又一次活生生的打了個人臉，個人程序在公測中crash了，緣由是數組越界。此次的做業要求實現一個傻瓜（FAFS）調度電梯，而且要求不符合要求的無效請求需馬上給出反應。所以個人程序設計成，當輸入無效時，指針減一。但若是第一條指令就錯誤的話，數組的指針就變成了-1，也就是越界了。這也就致使了在公測樣例中，只要涉及到第一條指令無效，那麼我就錯了。emmmmmm，越想越氣，這就比如你吃雞撿了個空投，你撿了一把AWM可是子彈忘帶走了。

      此次做業的難點在於判斷同質，個人方法是從後往前判斷，而且將指令分類爲：UP,DOWN,NULL(ER)，只有後一條指令和前一條指令類型相同，而且開始時間在前一條還未執行完成時，指令纔會判斷爲同質。這個方法存在着一些小bug，當時我並無de出來，可是在第三次做業中發現了，追悔莫及。

     

      第三次做業：

      Metric度量分析

        第三次做業一樣出現了方法過於複雜而且參數變量過多的狀況，一部分緣由是由於第三次做業是在第二次做業基礎上的繼承和重寫，而且要求實現捎帶功能。而我在ele_start()這個方法中，一是傳進了過多的參數，二是在函數中既要判斷同質，又要判斷捎帶，同時還得打印正確輸出。能夠說這個函數幾乎完成了我整個程序的主要功能。這樣的好處是，嗯，方便管理整個程序的運行狀況，壞處依然是可讀性極差，致使了我一點都不想debug。實質上，這個幾乎萬能的方法是不符合OO的基本思想的，對此我也十分慚愧和懊悔。

 

       類圖

 

       發現的bug、設計思想：

       第三次做業是我測試得最爲粗糙的一次，因爲時間沒有安排好，致使幾乎沒有時間去debug和發現問題，所以捎帶存在的問題很大，尤爲是同層實現兩個請求，而且是捎帶請求時，不能很好的作出判斷而且實行，同時連續兩個捎帶時程序也會出錯，這也是因爲我考慮不夠周到形成的。可是在此基礎上對第二次做業的改正是十分有效的，並無重複出現第二次做業的bug，對正則的使用也更加駕輕就熟。

       捎帶是此次做業最主要的功能實現，個人方法是使用一個變量loca，記錄主請求的位置，而後判斷接下來的指令存不存在捎帶的狀況，若是存在，就選擇一條最優，也就是離當前樓層最近的請求執行，當執行完全部捎帶請求後，回到loca的位置，執行主請求。惋惜的是，我花了許多時間也沒有de完個人bug。

 

心得體會：

        1. OO這門課必須花費大量的時間和精力去學習和體會，不只是面向對象的思想，還有設計思路的逐步完善和成熟，在動鍵盤前，應該至少有一個完整的設計思路，這樣纔會節省更多的時間，而且必須認真去理解指導書想表達的含義，readme也必須認真的去完成和說明。

        2. 對於這門課，良好的心態是必要的。在身邊的就有很多例子，互測的雙方由於對方比知道本身的姓名而肆無忌憚。也有人跟我吐槽，一門課把整個系的陰暗面都展示出來了。我並無遇到對我而言十分過度的人存在，咱們並不能以一律全，只能以一個良好積極的心態去面對每次挑戰。在抱怨別人給你找出bug以前，或者在給你readme挑錯以前，爲什麼不想一想本身的問題出在哪裏？爲什麼不考慮本身的程序爲何沒有完善？因此保持一個良好的心態吧。