OO第一階段總結

結構分析

　　通過對老師本次做業指導ppt的一番研究和拜讀，發現本身對面向過程式程序有着根深蒂固的眷戀。

　　不管是做業一，二仍是三，都出現了不一樣程度的方法代碼量不均衡的問題。尤爲是做業三，ALS調度類的核心方法行數超過二百行。

　　做業一中parsePoly方法出現超長問題：

　　

　　事實上，在分析本身代碼度量的過程當中，發現本身在前幾回做業中對類的用法和對面向對象程序的見解彷佛有着一些誤區。我有時爲了實現一個功能(函數)，去建立一個特殊的類，這個類剛開始甚至沒有特有的屬性，而在其餘類中調用時建立的對象只是專門爲了這個函數去建立的。在以後實現方法的過程當中，再爲這個類添加各類各樣的屬性，甚至有些屬性單純的是幾個方法要一塊兒使用的全局變量。好比在第一次做業中，個人ComputePoly類中有兩個方法，第一個方法是把字符串中的多項式提取出來並存在數組裏，第二個方法是把數組裏的字符串加在一塊兒。在實現的過程當中，我幾乎絲毫沒有體驗到面向對象編程的思想和優點，不少時候，我只是把類當作了struct和function的集合，但並無把對象之間的關係和所謂封裝理解清晰。

　　而第一次做業付出時間最多的，就是學習正則表達式，以及Java中相應的類的用法，好比Matcher類和Pattern類。在邏輯實現上並無遇到困難。

 

 

　　第二次做業有所改善，由於做業中出現了比較具象的電梯和樓層，我在編程的過程當中試圖去加入如 貓會叫，叫聲是喵喵喵、還會撓人，爪痕是balabala...... 這樣的屬性和方法，但在實現過程當中我確立了一條指令一條指令地處理的思想，由於這電梯有些Fool，就跟遛狗同樣，叫它去哪就去那，所以設計中構思的上一層，下一層，或者按按鈕等操做，都沒能用上，只是試圖引入了一些特殊的屬性用來判斷同質請求。判斷同質是此次做業的核心也是較難的問題，由於處理輸入輸出的部分在第一次做業中有了經驗，所以稍顯駕輕就熟。

 

　　第三次做業在第二次大致結構不變的狀況下重寫了Schedule方法，在我我的的實現中簡直就跟新建了一個類沒啥區別，由於我以前的scheduler類裏就沒什麼特有的屬性......這也所以致使了個人ALS_Schedule不管是代碼長度仍是度量中都顯示出無以倫比的巨大。

　　總的來講，第一階段做業中從結構來看我對面向對象程序的理解並非十分深入，但願在將來的做業中能有所改進。

BUG分析

　　從我編程的經驗和經從來看，bug有如下幾種：語言問題，邏輯問題，實現問題。

　　語言問題很好說，寫着寫着旁邊都是大紅叉就能夠邊寫邊de，編譯都過不了。編譯過了以後也會由於某些緣由直接Crash。所以善用搜索引擎，仍是很容易debug的。這種問題每每出如今初次接觸某種語言，不清楚語言的語法和語言的一些機制。我在某個同窗的博客中就看到這樣的例子：ArrayList加入某個對象時不是加入對象的副本而是加入對象的指針，致使同窗一個Temp從頭Add到尾都是一個Request。我在過程當中也遇到了如他通常的問題，能夠說是本身挖坑本身踩了。

　　邏輯問題，在面對指導書要求時的設計思路，設計思路若是有誤，在設計完成後想要更改每每須要花費巨大的時間，在我第三次做業的Coding過程當中，發現設計思路出現了一些問題，致使某個狀況下的捎帶識別須要直接重構邏輯才能解決，抓耳撓腮心態血崩。經歷一番思索才發現能夠取巧，幸虧不用改大致邏輯，要否則怕是得推倒重來了。

　　實現問題，在實現中或許會遇到不少的手抖，或者寫着寫着忘了，或者是其餘緣由。這些問題的體現有時是一個大於小於號，有時是一大段代碼的邏輯與指望偏移，這也是我認爲在測試中最難覆蓋的，由於你的問題不必定出如今什麼狀況下，或許它真的很特殊，分別測試功能都沒問題，一旦在某種狀況下，這個功能就會出現問題。而這些問題每每只能經過一行一行地調試進行解決，很是消耗精力和時間。

　　在個人三次做業中，bug的出現每每是由於疏忽和手抖致使的，有時很確信對一個狀況的處理徹底正確也會出現問題。

　　我在debug的過程當中發現，若是我能把代碼類似的邏輯整合，儘可能減小屢次判斷和重複的操做，不只下降了代碼量，還能夠有效進行模塊化，從而更容易地debug，所以在將來的程序實現中，我會逐漸調整編碼的方式與策略，儘可能避免這樣的bug出現。

心得體會

　　oo這節課確實很奇怪，有時候你們會說，oo確定不會比計組再難了。但在個人學習過程當中發現，每週學習計組的時候就比較有條理，有一個很好的網站能夠提供全部的資源和教學內容，這讓我學起來很輕鬆，也更願意去打開cscore。記得當時學計組的時候，一打開Chrome就會點上面的cscore網站。或許是聽了過多的傳聞，對計組比較恐懼，因此學習就很認真，也花了更多的時間。而oo，我分配給它的學習時間有些彆扭，由於在學習過程當中，我沒有一本合適的工具書作參考，上手基本全靠百度。事實上，我想實現一個功能，我須要的方法名字和類名字我是不知道的，也很難檢索它到底存不存在這樣一種方法。我要不就去看jdk裏全部的類，一個一個查，要不就去百度上試圖描述問題來碰運氣。所以我認爲學習過程當中一本深刻淺出的工具書是頗有用的，起碼看目錄能知道我都有哪些工具在編程中使用，不然會一直使用舊有的c語言思路。

　　談及對面向對象的認識，我能夠大體勾勒出一個好的面向對象程序應該是什麼樣的，可是本身實現起來卻有着大量的不同。好比電梯，若是我按指令進行操做，讓電梯上一層這個操做徹底沒有意義，而直接去目標樓層反而是比較簡便。所以我只能刪掉腦海中的電梯up方法，去直接建立一個setPosition方法。大量的set和get讓我以爲本身就是在用一個帶函數的類。不能訪問的變量就是這個類內部本身用的一些操做所需變量，能訪問的屬性就至關於c語言中的結構。這讓我對對象的理解有所恍惚。另外，我曾經想讓電梯去哪，再讓電梯直接輸出(5,UP,5)這樣的字符串，可是時間這個屬性在個人設計中只有Scheduler類裏擁有，若是交給電梯打印還要給電梯傳參，這讓我不由產生了這樣的操做意義何在的疑問。可是把打印寫在scheduler裏又顯得scheduler的職務過於複雜。有時我就是在這樣或那樣設計的糾結中慢慢壯大了本身的某一個類，最後造成的龐然大物削減起來卻又格外困難。不過我相信這樣的狀況會有所改善，我在慢慢的明確各種的職務和功能，也在慢慢地把它向指導書的要求靠攏。理想中的電梯機械音「6樓到了」，就是我想把打印放在電梯類裏的想法來源，這樣會增長設計的複雜性，但換來了職務的劃分明確。或許編程就是要費一些力氣，去讓將來的本身或者別人能更簡單的看懂代碼。由於代碼總歸是要維護的，前期的設計成本若是下降，寫程序不過腦子一直敲，那麼後期的維護成本也就格外得高。磨刀不誤砍柴工，爲了提升程序的健壯性和易讀性，我還有很長的路要走。