面向對象第一次課程總結

第一次做業分析

　　在第一次做業中，我設計了三個類 Parentheses、CurlyBraces、Test。

　　Parentheses類，存儲多項式中的每一項的係數與指數，具備將該項加入最終結果的方法。此類功能簡單，規模在20行之內。

　　CurlyBraces類，主要實現將輸入字符串中的一段轉換爲一段多項式，同時將多項式中每一項調用Parentheses的方法，對最終結果進行操做，實現「加減」，具體規模在90行左右。

　　Test類做爲主類，首先對輸入的字符串進行格式審查，將合法字符串中的每個多項式提取出來，使用CurlyBraces的方法轉換爲多項式，再進行進一步操做，規模在60行左右。

 

——第一次做業

　　圖中標紅的getPara()方法代碼長度有60行，主要是實現將多項式中的各個項提取出來，並將其加入到最終的結果中。在這裏，我手搓了一個狀態機實現將各項的指數、係數提取出來，致使代碼長度過長，但我的認爲，這裏的邏輯仍是較爲清晰的。

　　優勢：使用正則表達式直接判斷輸入字符串是否符合格式，實現較簡單。

　　缺點：

1. 因爲對java各類經常使用方法沒有了解，在將字符串中的數字提取成數字時，手搓的parseInt，形成代碼長度較長；

2. 未考慮正則表達式匹配時可能出現的問題，在對輸入較長字符串進行格式審查時，有crash的風險；

3. 類中的方法沒有作到相互獨立，加大了維護難度。

　　在公測時，沒有經過壓力測試的測試點，程序crash了。

第二次做業分析

　　在第二&三次做業中，設計了Elevator、ExpHandler、Floor、Request、Requestqueue、Scheduler、Main七個類。

各個類的屬性和方法都設計的沒有什麼邏輯，這裏就不具體分析了.QWQ

——第一次做業

——第二次做業

——第三次做業

　　在第二次做業的代碼中，主要仍是按照解決問題的步驟一步步的實現功能，沒有對各個類應當具備的屬性和行爲作進一步的思考。這也致使了在第三次做業基於此基礎上繼續添加功能時，代碼邏輯變得極爲複雜。在調試時，爲了解決一個BUG，代碼各個部分都須要縫縫補補，在這個過程當中，極可能一時疏忽就產生新的BUG。

 

反思和總結

　　在寫第一次做業以前，我對面向對象的思想沒有什麼瞭解，在編程時仍是以實現功能爲目的。嚴格意義上講，第一次做業我提交的仍是面向過程的程序，或者也能夠說是java格式的c程序。

　　在第二次做業中，調度器的功能較爲簡單，僅僅是按照輸入的順序執行指令，只是簡單的寫了個for循環遍歷一遍請求隊列就能夠知足需求，代碼規模也不算長。在編程時，將解決某些需求的方法提取出來，做爲一個獨立的方法，如去除字符串空格、檢查格式、提取請求等，但因爲在編程前沒有對具體設計作出詳細的規劃，各個方法應當放入哪一個類中考慮不夠周全，致使了各個類之間的邏輯十分混亂，並且仍是沒有作到數據結構和函數的相對獨立。

　　而在第三次做業中，因爲容許捎帶，指令執行的順序就變得複雜起來，我仍是傻傻的按照我第二次的寫法，沒有將判斷捎帶、輸出等各個功能寫在獨立的方法裏，致使調度器類中一個主要的方法代碼規模突破200行。在DDL前一天晚上，我發現了本身的一個BUG——當在同一層須要執行幾條請求時，輸出的順序可能出現問題。面對冗長的代碼，各類if-else if-else，在調試時，我遺忘了其中某個分支中相應語句的修改。最後還一頓使人智熄的操做，把調試過程裏，測試用的printf尚未註釋掉的程序交上去了.QAQ

　　互測又被發現了好幾個BUG後，我反思了一下，第三次做業調度的邏輯比第二次的複雜許多，再按照我第二次調度器類的一個方法裏實現不少個功能的寫法來寫，就將問題變得更爲複雜，也會致使各類奇怪的BUG——

　　1.不以(FR,1,UP,0)開頭時，判斷的邏輯有問題；

　　2.同質請求判斷，與電梯同層的指令判斷同質時存在BUG；

　　3.一次開門響應多條請求時，輸出的順序可能不正確。

 

　　因爲在第二次做業時就對問題抽象程度不夠，程序的各個函數又不夠獨立，在第三次添加功能時，將一種狀況的代碼改了，另外一種狀況的代碼卻忘了改。好比，我將判斷指令是否捎帶分爲電梯上、下行兩種狀況，而這兩種狀況又是在調度器類中某200+行的函數中的一部分的功能，而在這個函數中，同時還包括輸出等其餘的功能。調試時發現一個BUG，在對一種狀況的代碼進行修改後，還須要同時對另外一種狀況作出相應的修改，還要注意不要誤改了實現其餘功能的代碼片斷，這就極大地加大了調試的難度，還容易引起各類「神奇」的BUG。

　　DDL以後，實在是看本身的醜陋的代碼不爽，就將第三次做業從新寫了。重寫以後的代碼，基本作到了數據結構和函數的相對獨立。

——重寫後的第三次做業

　　雖然，還有不少不足之處，但較上一個版本，在程序設計和程序規模方面，都有不錯的進步。

1. 將實現不一樣功能的代碼段放進不一樣的方法中

2. 基本實現了對數據的保護

　　不足之處：

1. 對捎帶與否的判斷邏輯可否繼續簡化， 但它真的有那麼多條件啊

2. 仍是存在某方法功能不夠明確、代碼巨長， 但我的又感受沒有進一步拆分的必要

心得體會

1. 作程序設計前，仔細閱讀指導書，多逛各個討論區，對做業要求有更明確的認識，防止在編程過程當中反覆修改代碼；

2. 在開始寫代碼前，先將程序各個類要實現的功能設計好；

3. 必定必定要注意各個函數功能的相對獨立，在一個類裏某些方法實現的功能太多，調試時可能會付出巨大的代價。

 

　　 最後祝你，身體健康【霧】，再見