[BUAA OO]第一次博客做業

第一次做業

第一次進行面向對象的編程，不管是針對數據設計類仍是對方法進行合適的歸於不一樣類中，都不是很熟悉。所寫出來的程序仍是面向過程+有函數的類（雖然如今很大程度上感受起來也是這樣）。索性做業難度並不算高，完成的也算馬馬虎虎。公測都經過了，可是互測的時候被發現了一處筆誤，少寫了一個0，致使6位的測試樣例沒法正常讀入。而且因爲個人檢測輸入的實現並非經過正則表達式，而是經過簡單粗暴的有限狀態機，故而第一週並無完整學習正則表達式。雖然有限狀態機的設計並無出錯，可是沒有儘早學習正則表達式也給我後面的做業留下了隱患。

 

 

第二次做業

第二次做業對於電梯的設計要求並不高，除了一個須要排除同質請求的要求外，基本上跟遛狗同樣，哪裏有需求就去哪裏。對於這樣的設計要求，我設計了一個nextTime數組來存貯下一次這一條指令容許被點亮的時間開始點。在設計請求隊列的時候，我設計的方法是與前項的請求時間比較，可是我忘記了對即時項數減一，故而致使對於時間逆序的判斷恆爲正。致使公測有兩個測試點沒有經過。因爲我上次做業並無按照正則表達式進行設計，我此次的正則表達式其實是第一次設計。雖然沒有出現錄入時的爆棧，可是在字符轉換爲整形變量的時候沒有用try-catch進行設計，從而致使轉換的時候出現爆棧。真的讓我很心痛…這讓我明白按照公測樹針對性的進行測試輸入樣例的重要性，debug的時候必定要覆蓋到全部細枝末節，不能經過看和想來分析。

 

 

 

 

第三次做業

此次的做業險些血崩。因爲要進行指令的捎帶，也就意味着我上一次所設計的nextTime數組要作很大程度上的修改，不只next的時間要隨着指令的完成而變化，對於同質的判斷也要隨之而改變。這讓我真的頭疼不已。我以前瞭解到了第二次做業有的同窗使用了模擬時間的辦法進行設計。我認爲這種想法真的挺好，我當時認爲能夠經過設計按鈕（經過按鈕的點亮狀況指導電梯的移動、經過其亮暗的狀況判斷同質），來把複雜的對於指令的判斷交給所涉及的模擬來進行。可是，這種初期看似美麗的想法每每會變得很坑。隨着設計的進行，我發現，這種模擬實際上就是在設計一種有限狀態機，不只須要根據指導書中所說起的狀況來進行完整的cover，並且對於主指令以及捎帶指令的判斷是沒法避免的。由於指導書中要求對於不一樣的指令類型作不一樣的行爲（再次務必要強烈吐槽一下，爲何一次開門不能解決全部問題…）故而，實際上，不論作哪一種實現，對於主指令和捎帶指令的判斷和刷新是永遠沒法避免的。因而，我就經歷了天天中午美滋滋的覺得本身作完了，下午看客服羣&再讀指導書，發現了個人程序有無數個沒有正確實現的點，而後debug到一點鐘。這樣連續了兩三天…不過，這真的讓我明白了老老實實按照指導書所要求的進行實現是多麼重要。

 

 

 

對於大一的時候並無參加6系魔幻課程數據結構的高工學生來講，面向對象編程是咱們第一門大量碼代碼的科目。相比已經經歷過洗禮的6系同窗來講，咱們的壓力確實不小。不過，我想，學習是一個過程，縱使咱們起步慢，咱們也能夠追。對於程序的設計和維護也是一步步進行的，但願我再接下來的無數個做業中能作的更好。