oo修仙之路
寫在前面：
之前聽說過oo這門課的威力，計院全體修仙現場的圖也被轉了不知多少遍，然而自己不親身經歷就不知這門課的難度所在。每次debug時耳邊總會想起三國殺裏面周瑜的話“掙紮吧，在血和暗的深淵裏；痛苦吧，在仇與恨的深淵中！”oo對我來說大抵就是這樣，痛苦卻無法避免，下面就來回顧一下這一個月以來的oo生涯。
第一次作業：
第一次作業我美滋滋地以為老師會講Java，像c語言和數據結構那門課一樣，第一次作業並不會太難。然而我太天真了，第一次作業就給了我致命一擊，看著如同天書一般的指導書，生平第一次懵了。正則表達式是什麽？老師連Java基本語法都不教的嗎？（老師：沒錯兒~）馬克思說過：當你不會寫代碼的時候，你就去多看看別人的代碼，學習學習就會了。（馬克思：我沒說過）於是秉承著這一理念，我去問學長要他的代碼看看，試圖從中分析出一些東西。然而，不會基礎語法的代碼就像一盤散沙，不用run它自己就散了，我並沒有分析出任何東西並且寫出了一灘狗屎。這個時候我才想起來，應該去好好聽聽基礎語法課，看看基礎語法的書。這是我第一個致命錯誤。
第二個錯誤就是我沒有一個良好的規劃，這也是我在三次作業中犯的共同錯誤。因為這個原因，我常常搞不清我現在在幹什麽，下一步要怎麽做，也導致了寫代碼時本來應該先完成基本功能再去往裏面加東西，我卻是寫著寫著就加進去了，導致後面工作無法展開，一塌糊塗。
第一次作業是處理多項式加減運算的模擬計算器，說到底我寫的還是一個面向過程的代碼。在讀取時，采用了逐字符讀取的方法，由於正則表達式沒能學好，最終還是選擇了狀態機。而由於狀態機的問題，對於正常輸入也總是報錯，導致了代碼正常功能測試沒有通過，成為了無效作業。之後在課下想通原因進行了調整，重新用正則表達式寫了（在這裏我要感謝實驗課，不知道為什麽有些東西在課下怎麽都想不通，一旦上了實驗課，在ddl的奪命連環call之下，一下子就想通很多問題！真的太神奇了！小嶽嶽臉.jpg）。但第一次挑戰依舊是gg了。在這裏就不放第一次作業的類圖了。（就一個類而已！請你閉嘴好好反思行嗎！）
勝負乃兵家常事，大俠請重新來過！
第二次作業：
第二次作業gg的理由非常簡單，我作死地讓命令行輸入要進行的電梯操作，讓控制臺輸入“run”，這樣公測當然通不過啊！！！公測怎麽有那麽智能？！這個gg的理由被我們宿舍笑了好久，我也想乘坐時光機回去問問我自己到底是怎麽想的啊……
放上修改以後的類圖（我以後再也不想碰命令行了……）：
這次作業寫起來還是很困難（這不是廢話嗎……第一次作業就那麽艱難），主要原因是我不明白為什麽需要五個類，這五個類到底要幹什麽，他們之間的關系是什麽。在詢問過某位大神之後，終於對於面向對象有一點點理解了，也明白在面對一個項目時，要怎麽去分析和設計。
本次作業要構建一部傻瓜電梯，使用五個類完成，Elavator類共有5個屬性，3個方法，分別實現返回時間，樓層，計算上下樓層所需時間並更新當前樓層的功能。
Floor 類十分雞肋，沒有程序應用上的作用。
Request類有4個屬性，6個方法，分別實現返回目標樓層，時間，請求類型 ，電梯運動方向，對這些變量的賦值和計算賦值。
Requestqueue類中有1個屬性，6個方法，方法規模都很小，只負責返回請求，計數及將新的請求加入到隊列。
Dispatcher類類中有2個方法，其中一個用於建立隊列處理輸入，另一個用於返回隊列。
第三次作業
第三次作業說起來輕巧，是在第二次作業的基礎上增加“捎帶”功能，然而真正寫起來復雜程度超出了我的想象。過分細化的定義讓人一頭霧水，而這也是第一次有效作業emmm……應該說還是挺開心的，看到作業有效後狠狠哭了一場，有一種修仙小說中凡人剛剛達到煉氣期踏上仙途第一步的感覺。
話不多說放上類圖：
我的bug：
這次作業公測掛了三個點，第二次作業對於同質請求沒有寫好，導致了第三次作業掛在同質點上了。自己在給別人測的時候發現了一些我程序上邊界點的bug，
但是給我測的那位同學沒有發現orz沒有被報bug雖然挺開心的，但是並不能說明程序就真的沒有bug了，還是要努力改正。
別人的bug及測試方法：
在宿舍同學的指點下，我發現可以根據測試樹先全面地寫一份測試用例，互測時全部跑一遍。
通過這個方法找出對方非常多bug，比如說時間限制、亂序處理、捎帶不捎帶、同質不同質……
閱讀對方readme中的各種規定，有時從他的敘述中可以發現邏輯上的錯誤，進而構建測試樣例（那豈不是美滋滋，而且第三次作業但凡涉及捎帶問題，up和down對偶性構建測試樣例，一查一個準）。
這個就有點困難了，而且有種語文作業咬文嚼字的感覺，在身邊同學幾次撕逼的過程中也發現，基本通過這種方法找到的bug就和甲方乙方互相不理解一樣，各說各有理，我個人不是很喜歡這樣測試。
不過為了避免被別人通過這種方式構建，還是要好好寫自己的readme！
最後就是仔細閱讀別人的代碼，發現其代碼中的不足從而測試
對於目前的我來說，這幾乎是不可能的。我ball ball各位大佬們下次能不能給自己代碼寫上註釋，寫註釋看起來都很困難，不寫註釋是真的要很久才能看懂（所以我放棄了）
一些心得體會：
- 不拋棄，不放棄。第二次作業無效的時候已經考慮退學了，最後被現實一個巴掌扇了回來（拿不到大學畢業證書真的太難生存了）。哭著跟父母說我不上了，反正也學不會，最後想著能學一點是一點，硬著頭皮去看書敲代碼，邊哭邊敲，居然也熬過去了。當然在這期間少不了很多人的幫助，想想之間鉆牛角尖走不出來的日子只覺得可笑，逃避解決不了任何問題，只能讓自己變得越來越差。不要把oo當成洪水猛獸，當成修仙好了（23333），剛剛踏入仙途，還沒築基，會面對很多困難。修仙路上是有天才，資質較好，年少便已名揚四海，像我這種呢，就是個外門小弟子，能力不強，心魔還挺重，但是為著未來或許有的一點希望，還是要努力地去拼搏啊。
- 認真對待每一次作業，要有清晰的思路分析，而不是像我一開始一樣東一榔頭西一棒子。魯迅說過，只有經過設計的程序才是好程序。（魯迅：我沒說過）為什麽一直浪費時間卻做不出來，很大一部分源於沒有認真設計該如何構造，才導致後期越來越模糊越來越不知道怎麽寫。
- Bug一定要改，雖然我嘴上說著“除了crash問題其他bug我絕對不改了”，但是身體還是很誠實地去改bug了為什麽啊！因為後面的程序是在這個程度上疊加的，如果現在的bug不改，之後可能會出現大問題。
- 互幫互助、團結協作。這是oo讓我意識到的非常重要的一點。沒有人是一座孤島，一個人的bug可能是一群人的bug，同樣，一個人的數據也可以是一群人的數據。這門課不是養蠱，一個個鬥個頭破血流你死我活才算勝利。誠然，互測中有惡意扣分的現象，也絕對無法達到烏托邦的理想世界，但是我還是想說，這門課重要的不是你給別人扣多少，而是你能不被別人扣多少。
- 鍛煉身體，好好修仙。熬夜到喝速效救心丸的經歷我不想有第二次。
言盡於此，興致闌珊，還是那句話，願天堂沒有oo。
oo修仙之路