OO前三次做業簡單總結

隨着幾周的進行，OO課堂已經經歷過三次課下做業。在這三次做業中，我被扣了一些分數，也發現了本身幾回做業中一些存在的共同的問題。

首先以第三次做業爲例分析，我程序的類圖以下

 

 

一共九個類，其中Als_scheduler是Scheduler的子類，兩者分別在第二次和第三次做業中進行總調度。Request類是請求類 Requestqueue類是請求隊列類，負責將輸入的若干請求做爲隊列處理。Lift是電梯類，負責電梯的處理。FLoor類是樓層類，負責生成樓層類請求。具體流程以下:

1.程序以Main方法做爲入口，而後以Reader方法來處理輸入並將請求添加到隊列中，其中調用了RequestQueue類的AddRequst方法來處理添加操做。

2.Reader類中也處理了不符合順序或者不符合輸入格式或者數據溢出的請求。

3.在Als_scheduler類中的smarterRun方法中進行調度,該方法是Run接口中的方法的實現：

①新建一個Reader類的實例，讀入輸入的請求。

②判斷讀入的請求是不是同層移動的請求，若是是，說明不可捎帶其餘請求，直接

用ExecuteAndPrint方法響應該請求並輸出，而後尋找並刪除同質請求，將已經執行的請求從請求隊列中移除。

③若是不是同層移動的請求，便針對Lift類的實例，也就是電梯，一層一層模擬電梯移動，每移動一層遍歷主請求完成時間前的全部請求，判斷符合時間的請求可否符合捎帶條件，用AcanTakeB方法來判斷，若返回True，則添加到捎帶隊列。遍歷完請求後遍歷捎帶隊列，若是能夠在電梯當前層執行，則用ExecuteAndPrint方法響應該請求並輸出，並把相應的時間推遲。直到電梯移動到主請求的樓層並執行。執行完主請求後，若是捎帶隊列還有請求，則把第一條升級爲主請求，接着執行。

優勢：對於面向對象的思惟和運用有了初步的認識，流程基本上也算是清晰。

  嘗試着使用繼承、接口和接口的實現、抽象函數等來進行編程，這很面向對象。

  命名逐漸規範。

缺點：耦合度仍是不夠低，有些地方改起來仍是牽一髮而動全身，不少內容能夠再抽象出來成爲一個方法卻沒有抽象出來，這樣修改起來的時候很麻煩，可能仍是受面向過程的編程影響。

·對於輸入的處理很差。起初我沒有利用正則表達式來處理輸入，而只是想着簡單地使用split方法來處理輸入，結果不只多了不少行沒必要要的代碼，並且對於一些諸如(FR,1,UP這樣的輸入沒辦法判別爲無效輸入。我在作的時候也沒有考慮到這些，以後發現了這些問題，我學習了正則表達式的使用，在輸入的處理上基本上沒遇到問題，可是浪費了不少時間。

·第一次做業對Exception進行catch，卻沒有catch到Error這個類的對象，對於十分巨大的輸入出現Error致使crash。

·第二次做業的正則表達式判斷上，我對前導0和前導正號的處理有一些遺漏。

·對於指導書的理解不深。第三次做業中一些是否捎帶的問題我理解彷佛和指導書有出入，也沒有在討論區進行進一步探討而是理解爲本身會了，就直接致使了我一些樣例的出錯。

·自我測試較少。做業完成進度較慢，沒有進行必定量的自我測試就提交，一些是由於本身粗心的能夠避免的錯誤沒有發現。

問題所出現的類，第一次做業在多項式輸出的處理上，也就是單項式和多項式類，輸出個數能超過20個多項式和50個單項式的限制，然而由於第一次做業我採用數組的數據結構，數組開得太小，致使溢出，所幸我catch到了這個Exception沒有致使crash，可是也沒有輸出正確結果。

第三次做業只有同層的輸出順序上的BUG，沒有大問題，還好。

發現別人的Bug主要仍是在一些邊界狀況較多，首先簡單閱讀代碼結構，若是他的代碼主要邏輯沒有問題，則重點關照一些邊界狀況，好比小數，小數的精度；或者一些邏輯上的邊界狀況，好比反覆走走停停的電梯等。

其次精讀代碼，觀察他人有沒有一些設計上細節的小瑕疵，因此咱們本身在編寫代碼的時候，對於細節也要細心。

總之，在咱們編寫代碼以前，最好對於咱們的這份項目，有一個總體上的結構認知，最好先畫出類圖和關係，再根據類圖來編寫代碼，這樣結構清晰而嚴謹。

在測試本身代碼的時候，要懷着測試他人代碼的心態來反覆找錯；在測試他人代碼的時候，要懷着測試本身代碼的心態而一絲不苟。