OO第一次總結

OO第一次博客--前三次做業分析：

第一次做業：

第一次做業的要求是實現有必定魯棒性的多項式加減法。對於大多數剛開始接觸JAVA語言和OO思想的同窗來講，此次的難點主要是：JAVA語法、面向對象思想、正則表達式的使用和程序的魯棒性。相比覺得的語言，我沒法理解「面向對象」這個詞的含義。在膜拜已經對java有所理解並上過面向對象先導課的大佬們的代碼後，我才稍微對「面向對象」的寫法有所理解。雖然聽起來很不現實，但在瞭解了一個語言的基礎語法後，參觀和學習大佬們的代碼彷佛是快速上手的好方法（這彷佛與課程要求相違背但對於學習確實有所幫助）。在聽學姐講解後，有據說正則表達式是一個便利的工具，便利用之。對於程序的正確性以及如何保證不crash，除了本身多加try來注意，還須要大量的測試驗證了。畢竟本身測得不夠全面，就只能指望別人也不幫你測。。。

在設計上，我採用了一個Poly類型的數組Polylist來存放各個合法多項式，在首項前加「+」，再利用找操做符號來分割各項進行操做。這是一種常見的操做，效率算不得很高，但好在不至於超時並且很便於理解。

如下是其類圖及其度量分析：

從度量分析中看出的是Match方法被標紅；該方法是本次做業中個人主方法。。。

（附：McCabe Cyclomatic Complexity（圈複雜度）用來衡量一個模塊的複雜程度，統計一個函數有多少個分支(if,while,for等)，沒有的話複雜度爲一，每增長一個分支複雜度加一。圈複雜度的做者McCabe認爲，圈複雜度在3~7爲比較好的結構化方法，圈複雜度大說明程序代碼可能質量低且難於測試和維護。Nested Block Depth（塊嵌套深度）則爲嵌套深度。這兩塊出現超標，每每說明程序設計有缺陷，或部分代碼嵌套深，難以判斷邏輯，或直接寫成了面向過程的思想。）

做爲一個菜雞的第一個java程序（除了HelloWorld），我代碼中的問題不少：

首先是對java語言的不熟練致使到處像C，也直接致使了一個函數到結尾（就像main）。另外由於初學面向對象編程，致使代碼中對於對象的重視不夠，更多則是在面向過程。。。

而本身被爆出的bug中也體現了本身對代碼的理解不深入：被人爆數組（公測一樣在爆但僥倖逃過一劫），對方刻意構造大型錯誤輸入，瞄準我在錯誤輸入處理時想固然的隨意開了一個小數組來儲存結果，被爆兩組數據。這也讓我在以後的兩次做業中debug和找bug時對於代碼中的數字更加劇視。

 

第二次做業：

傻瓜電梯的設計與驗證。傻瓜電梯的難點，應是對電梯的設計上，即如何實現電梯、分別給五個或者更多的類什麼功能、各個類之間如何串聯等問題上。我採用了dipatcher類對操做進行處理；而電梯類elevator和floor分別存儲電梯在該指令執行完成先後的時間、樓層、運動狀態，並給調度器計算指令完成時間。指令demand負責讀入，在work函數進行輸入篩選處理後將可執行的傳進指令隊列，再從頭開始逐條傳入dipatcher取出處理。

此次的做業相比第一次做業，面向對象的思想體現的就明顯多了；指導書中對於多個類的提示也在把咱們從面向過程的誤區往出拉。

如下是其類圖及其度量分析：

 

 

從類圖中能看出demand類幾乎是沒有起到任何做用，由於只是在work函數對輸入進行暫存，進行篩選以後直接就傳給queue了。。。甚至沒有均可以。。。這帶來的問題也十分明顯：queue類過於龐大了，在第三次做業中更會有所體現，這又致使了個人數據結構複雜冗餘，本來demand中應該實現的分類只能在queue中狂開數組來分類保存。。。在調度時也麻煩的一逼。。。

好在做爲第二次做業，相比上一次的青澀少年我也是有了第一次經驗了。。。在數據處理上稍微嚴謹了一些，不幸地是，此次我被爆出的問題比上次還要多：

1. 對分支結構的處理太過傻逼。在處理錯誤輸入時，由於經驗不足，面對諸多錯誤狀況自亂了陣腳。。。一大堆的if,break,和flag自增在公測的幾個小數據面前就開始瞎幾把輸出（對錯誤判斷後的處理太混亂），好在爲第三次提供了寶貴的參考。
2. 採用了奇怪的計數和循環：do-while和一個從0開始的count，判斷條件裏的是[count-1]元素。。。有一個事先考慮大條致使了只有一個RUN的時候數組越界（count-1<0）。。。
3. 對指導書的理解不深入：指導書中對於「第一條指令時間不爲0按crash處理」的描述，被我簡單的理解成了直接報錯結束進程。。。結果掛了兩組公測數據。。。也是參考。。。

度量分析中紅色的是新加入的度量類，幾乎是代碼中的核心處理部分，說明了我對於指令的處理仍是應當有所精簡。

 

第三次做業：

學長口中的第一個「很差寫」：ALS電梯。

此次電梯的最大改動爲容許捎帶，這就出現了主指令和最多兩條捎帶指令（即若存在捎帶，能找到一條最早捎帶的指令，以及可能會找到一條和它僅指令標識符不一樣的指令一塊兒被捎帶）。所以排在後面的指令有可能被先完成，不能單純只從從隊列頭開始向後一次遍歷。將全部指令按樓層進行儲存。再使用了一個指令隊列，規定頭指令爲主指令，再每變更一層後判斷同質，向後找最優捎帶指令，執行後將其標記,再也不執行。當全部比主指令先執行完的捎帶指令所有完成，執行主指令並從隊列刪除，將新的主指令置頂。循環下去至隊列爲空。然而在完成代碼的時候，仍是被炸出了一些奇怪的bug（主指令爲同質指令時沒有將其篩除，說到底仍是判斷邏輯不夠完備）。此外，要求使用對於咱們菜鳥來講新學習的繼承、接口、重寫。。。（然而慚愧的是本身代碼中幾乎沒有對這些的體現。。。接口無用，繼承基本全是重寫。。。）

做爲單線程第二次電梯做業，她已經向現實中的電梯有所靠攏。。。同時對於咱們第一次的電梯要求更高了（得先調好第一次才能避免第二次出現上一次的bug）。遺憾的是仍是出現了問題（上面已提到）。。。

如下是其類圖及其度量分析：

 

 

度量中體現的仍是老生常談的問題：depatcher的龐大。而致使這些的緣由之一是對數據結構的組建太混亂（第二次中的queue在本次中不減反增）。。。

好在debug方面總算把第二次的問題解決了，但是測試數據太弱仍是沒能發現一些特殊的問題，好比提到的主指令爲同質。。。以上這些緣由這也致使了我後來de了很久也沒de完。。。

 

至於心得體會，從一個菜雞的角度來看有如下幾點吧。。。

1. 基本語法得學明白。。。Java做爲新的工具，欲善其事不利其器是絕對不行的。。。否則就會出現像我同樣申明數組卻沒有沒有挨個實例化的de了很久bug的傻叉行爲。。。
2. 打出提早量；週二晚上寫確定寫不完，除非你通宵。。。
3. 多向大佬們學習；這很重要，菜雞閉門一個月造的車也不必定跑的過大佬三天寫的sports car。。。畢竟一個月的學習和大佬幾年的積累仍是沒得比，面對人家的豐富經驗，咱們仍是要多學習。。。（遺憾的是不少大佬並不肯意分享代碼）因此咱們要多接受大佬的點撥和教育，這是咱們儘快走向熟練甚至成熟的不二之法。