OO第一次課程總結分析

---

　　做爲一個以前從未使用過java語言，主攻面向過程式編程的「面向對象」小白，因而乎從第一次做業開始時利用時間瘋狂學習java語言，通過三次做業的殘酷洗禮，本身對面向對象式編程多多少少有了初步的瞭解（前路漫漫，任重而道遠）。下面針對以前的三次做業進行總結分析，以及本身這一個月來的心得體會。

  

第一次做業：一元多項式加減運算

---

 

　　此次做業可謂是與「面向對象」和「瞌睡蟲」對決的開始了。第一次接觸這門語言和這種思想，尚未養成相應的思惟習慣，因而基本就是按着面向過程的思路來完成的。整個程序只有一個主類、一個主方法（全部處理都放到主方法中去了），值得慶幸的是用到了正則表達式（現學現用）來規範輸入。主方法主要是開了四個數組來分別存儲結果多項式與輸入多項式的的係數和冪，進行相應運算，利用數組下標和冪相等的關係遍歷數組來實現升序輸出。

　　公測被測出的bug是壓力測試的分支點，由於輸入太長的緣由程序沒有輸出預期的結果。互測被測出的bug是因爲判斷同一個多項式不能輸入相同冪項那裏邏輯不夠嚴密，致使同時輸入幾個相同0次冪項時程序不報錯。分析以後程序應該就是不能判斷相同的0次冪項，其餘沒啥大問題，看來本身測試的時候還欠缺考慮啊！

　　至於我測出的bug，先是看了一遍被測者的格式規範判斷，他也用了正則表達式，但跟我印象中的略有出入，因而就在格式的邊緣瘋狂探索，終於找到了他的格式錯誤。還有就是我本身準備的殺手鐗（本身一開始寫的時候容易忽略的地方），就是第一個多項式前有符號的狀況，那位老鐵沒有考慮到，也被我給逮着了。

　　下面是個人度量分析和類圖（也就僅僅一個孤獨的類而已）

 

                                                                                                   

 　　經過metrics圖可以看出main方法的圈複雜度太高，塊嵌套深度過深（畢竟本身全部處理都放到main方法去了……）。

 

第二次做業：傻瓜電梯

---

 

　　這回照着指導書寫了幾個類，姑且算是套上了面向對象的外衣，Request類裏只有請求的屬性和構造方法（這或許是我寫的最自豪的一個類了），RequestQueue類裏我將數組的計數器和數組當作靜態變量使用（emmmm,這彷佛悖與數據封裝），方法就是將有效的請求存進數組。主類的main方法主要是處理輸入字符串和輸出錯誤狀況的事情（不敢在main方法裏放太多東西了）。而對於Scheduler類，唉！仍是來看度量分析吧！

                                                                             

　　一如上次，仍是這兩處變紅，看來個人調度器仍是寫了太多東西，判斷同質，輸出電梯狀態等處理都放到Schedule方法中去了，使用了過多的條件判斷語句。

　　這回被公測測出了兩個bug，一個是沒有判斷輸入時間過大應該報錯的狀況（真應該抽本身一遍爲何不仔細去看指導書的要求），另外一個是沒有忽略不一樣時刻的同質請求，這回真的是本身疏忽了，沒有考慮到當一個請求發出時間大於電梯時間的狀況，致使時間錯誤，沒能判斷出同質。

　　此次整八百遍我仍是沒找出那位老哥的bug，因而就從readme下手，還真找到了一個輸出與readme規定不符合的bug（看來檢查一下readme也是一件重要的工做啊）。

       整體來看，相比上次做業有了一點點進步吧，可是對面向對象的思想了解仍是不夠透徹，還須要進一步學習。

 

第三次做業：有一點小聰明的電梯

---

 

　　電梯耍了一次小聰明，我卻不得不用幾天幾夜的爆肝來應對。雖然說表面上只是加了捎帶這一個功能，但細細分析彷佛捎帶跟同質纏在一塊兒，仍是挺複雜的。此次的核心部分是再寫一個新的調度類來適應新功能。電梯在往上的過程當中，每到一個樓層就尋找這個樓層須要捎帶的請求，而後執行的同時也判斷該捎帶請求的同質請求，將其標記，再也不執行同質請求，對於執行過的請求，也進行標記，再也不執行。

                                       

        經過度量分析能夠看到，我此次的程序雖然實現了功能，可是幾乎所有功能的實現都在Schedule_son這個方法裏，代碼顯得臃腫，重複性很高，這是一次很大的錯誤，值得檢討，類之間的分工不均衡，這是目前本身程序的最大問題。

        此次公測卻是沒有bug，互測階段被測出的兩個bug幾乎都是判斷條件不充分引發的，由於同質引起的錯誤，由於代碼臃腫，改起來工做量也不小，本身看的眼都花，有這種錯誤也是本身設計方面的問題，本身的思想還不夠深刻。

        此次拿到的同窗的代碼很漂亮，沒有什麼bug，其實互測也是一個學習的過程吧，至少我看到本身的不足。

 

最後的心得

---

 

1.千萬千萬不要拖，若是由於拖延症而「死」，相信你本身也不痛快。

2.看清指導書的要求和理解指導書的需求，先清楚本身要實現什麼纔開始構建動手。

3.堅持寫完，不要有那種認爲沒時間了、太難了寫不了的思想，堅持寫，就算還寫不出，也總比放棄好。

4.程序在進行格式檢查的時候使用正則表達式是個不錯方法。

5.使用try-catch，不要讓本身的程序出現crash，這是大忌。

6.在提交以前要仔細檢查，本身多測幾遍，看一下readme的規定是否與本身程序實現的一致。