OO第四次博客做業（第四單元做業及期末總結）

（注意：本文寫做順序與做業要求不徹底一致，但涵蓋了做業的全部要求）

　　一學期的BUAA特點OO課程結束了。

PART 1  我想先寫我這一學期的感想

　　從第一單元滿懷期待地寫完多項式求值到最後看着60分不到的成績傷心欲絕（這個詞用的其實並非特別誇張），到第二單元做業在截止前兩小時還在作不停地思考和調試，再到第三單元在活頁紙上記下一種又一種可能的實現方法（而後還有一堆bug2333），最後到第四單元，也就是這個單元的與考期共舞，與程序廣度做鬥爭，每一個單元都是你從未玩過的船新版本（由於OO課程改革因此還真的是船新版本），每一次做業都帶來徹底不一樣的體驗。雖然寫做業的期間，不只是我，好多人面對滿屏的代碼和各類各樣毫無邏輯的bug陷入自閉，但一旦挺過來，回頭一想，本身確實完成了一些規模比較大，架構較爲複雜的項目，並且是在比較短的時間限制內完成的，雖然仍是不能從根本上改變鹹魚本魚的本質，但至少算是作了比較大的努力，實現了一些之前本身不敢想的事情吧。從一學期的OO課程一步步走過來，回過頭髮現，本身真的走過了一段很遠的路了。

PART 2  寫完感想再寫一寫對OO課的祝願，感受這樣行文比較流暢

　　以前的博客做業沒少發過牢騷了，這一次，做爲課程的結束，想發自心裏祝願這門課在之後能愈來愈好，能爲學弟學妹們提供更好的指導做用。雖然，按當今的社會情況，不要說一門課，經過整個大學階段的學習，也很難從本質上改變乃至塑造一個成功的人，就比如只能對一棵已經長成的樹作一些修修剪剪，而不能從一棵小樹變成一棵參天大樹。可是，我仍是但願，哪怕只是想象一下，讓學了這門課的學生，至少有一個自信，他可以勝任一些中小型的企業工程項目（更激進一點的想法，應該是大中型），有能力去企業作一些相關的實習，更好地與將來的工做相接軌，而不要讓他們感受本身不管學沒學，都仍是一條不中用的鹹魚。

　　若是說具體作法，首先既然談到實習，那若是有可能的話，能夠真的爲學生提供哪怕只是一週，或者一箇中型Project的實習機會，去與工業界最親密地接軌。可能對於至關一部分人（也包括我），仍是須要以相似於做業的形式進行逼迫（或者說被動）式的學習才能真的吸取一些東西，既然這樣，那把他們置身於工業界，置身於職場，在那種緊張的環境下，多是對他們更加直接的逼迫，讓他們感覺到從構思到測試以致release的每一環節的不可或缺，全過程地感覺「鋼鐵是如何煉成的」，這裏的鋼鐵固然是代碼的「鋼筋鐵骨」。限於條件，也能夠進行相似於工業環境的模擬，但總歸是差了點感受，尤爲是在測試的迫切性上。感受只有置身於工業級的程序發佈環節以前，纔有那種必須不斷、反覆進行測試的必要性和緊迫性，纔會真的想去一遍又一遍地進行各類測試。

　　另外，若是侷限於做業的形式，我以爲咱們寫的程序雖然在難度上真的不低，但距離一個真正由現實用戶使用的程序，還差了一個難度上不大，但對絕大多數程序都不可或缺的環節——圖形用戶界面GUI。雖然通常的程序設計課上，不太可能單獨掏出一個板塊來說解GUI的設計，但咱們BUAA的OO原本就不是通常的程序設計課，它是基於project來實踐練習的課程，既然如此，何不讓課程內容覆蓋更加完整，來一學期」從內到外「的面向對象編程練習呢？我的甚至腦補了一個具體的實現方式：在project總數不變的狀況下，把JML第1、二次做業合併，擠出一個作GUI做業的project（我的感受，在工業上與學術界普遍使用的UML，比實際用的很少的JML反而少一個project，自己就不怎麼合理，感受UML是一張真正的藍圖，而JML更像是一種玩具），在最後一次做業中完成一個GUI的設計。測試時若是沒法實現機評，就用人工檢測的方法，檢測程序是否可以經過圖形界面操做，實現對應的功能。這樣一來整個project的難度其實會相對簡單一些，必定程度上減少了烤漆複習的壓力。還能夠採用比較特別的性能分區分方式{好比按UI美觀程度給分，固然不要太過度，只要不是BAD UI就拉滿），給以前單元學到快自閉的鹹魚們一個翻身的機會，畢竟做爲一門課程，給予學生充分的自信心是必要的，總不能讓人一直coding司馬臉，debugging司馬臉吧。

　　上面的建議可能太過空想化，僅僅做爲我我的的一點祝願寫在這裏吧。另一些細枝末節的建議，就是儘可能讓每次指導書的要求明確一些，不要有bug或者含混不清的地方吧。固然這個事情是不能強求的，我本身寫的程序都有一堆bug，又有什麼資格苛求別人呢。

　　（以上三段在統計時每段算作一個建議吧，太長看不過來的話）

PART 3  迴歸本單元做業

　　兩次做業放在一塊兒講吧，懶得分段了，況且它們是包含而不是並列關係。

　　這單元的做業，從難度上可能不是特別大，但廣度上真可謂無可匹敵。先是關於UML類圖的各類操做，後又擴展到順序圖和狀態圖，還要實現對類圖的基本規則驗證。這就直接致使了一個結果：最後一次做業的代碼量遠超以前任何一次做業，成爲爆肝的有力見證。

　　一開始我想直接採起遍歷輸入的方式實現每一個功能的操做，結果證實行不通（這不是必然的嗎？）。以後便老老實實地按UML結構創建了保存類模型的struct，從class，到attribute、operation，再到parameter，一級一級創建起來一個完整的結構，也就意味着說初始化的時候要遍歷至少三次輸入。類和接口採用同一個結構模型，只用了一個boolean變量來區分兩者。對於繼承、實現、關聯等各類各樣的關係，採用兩頭區分的方法，以繼承爲例，有一個保存父類的ArrayLIst AppendFromList，也有一個保存子類的ArrayLIst AppendByLIst，這樣就將全部的輸入信息轉化爲便於處理的，相似於圖的結構了。對於UML順序圖和UML狀態圖，我也採用了相似的處理方式。實際上，此次做業中至關的碼量和時間，耗費在告終構的構造和構造方法的書寫上。

既然這單元學的是UML，那我就導出一個超級大的UML類圖放在這裏吧（手動滑稽）

　　代碼的核心邏輯部分，我以爲本身真的是吃了數據結構，尤爲是圖的部分沒學好的虧，老是出問題，出各類問題，害得我半夜3點又燒腦又爆肝地debug。就算我投入了大量精力思考致使bug的緣由，就算最後一次做業要求已經簡化，強測的bug最後仍是出在了圖結構上。第一次的bug沒什麼好說的，沒完成指導書要求（還真不是沒看，解決方法都想出來了，感受本身明明寫了，結果發現沒有，晚了！）加上迷信指導書樣例，忽略了接口重名要重複輸出這一點。第二次的bug，checkForRule008改了好幾回仍是掛了一個點，暫時先無論了，專心把博客寫完，你看又半夜12點了。

PART4 總結四個單元架構設計和OO方法理解的演進

　　由於寒假預習工做作的不錯，至少在理論層面，對OO方法已經有了必定的理解。

　　第一單元：理解歸理解，在至關多的地方，面向對象的方法沒怎麼體現出來，無非是將表達式拆成了三個部分。但就是這門一分，帶來了面向對象給我帶來的第一份便利：化整爲零，用簡單、細小的部分拼湊成複雜的、龐大的部分，用簡單、短小的方法去實現複雜、冗長的方法。雖然構造方法上，結構式編程的痕跡還很是明顯，但封裝、繼承、接口實現等基本操做已經獲得實現（P.S. 如今想起來第一單元做業還重複繼承過接口2333），到第三次做業，已經不可能再用結構式的思惟去實現，而憑藉前兩次做業的面向對象基礎，就比較輕鬆地完成了。

　　第二單元：與其說面向對象，不如說這一單元演練的是多線程編程的能力。可能在寫的時候，並不以爲由於面向對象帶來了多大的便利，不事後來證實那是由於多線程編程自己的難度，而不是面向對象方法不行（寫完OS Lab4的fork函數就知道了）。這單元是最難的一個單元（雖然就這麼一句話讓我每次都有後面單元很簡單的錯覺，而後每次都寫到自閉），最後一次做業更是難上加難，電梯的封裝、調度器的實現、調度算法的選擇、多個電梯線程與調度線程和輸入線程的同步，隨便一個均可以難倒一大片人。儘管最後沒有可貴地沒bug實現了，但面向對象的程度還不夠，代碼耦合性比較高。

　　第三單元：此次絕對是正宗的面向對象編程了，惋惜封裝的部分不是咱們親自完成，而是助教幫咱們實現的。架構上也並不困難，就是典型的無向帶權圖，加上嚴格的卡時間限制，彷彿穿越回了一年前的數據結構課堂。但與以前不一樣的是，此次是採用面向對象方法實現的圖結構，用更少的碼量、更清晰的程序邏輯，實現了更爲複雜的功能。

　　第四單元：和上次相似，也是助教幫助咱們進行的封裝，並且此次幫得能夠說更多，以致於架構佔了碼量的大頭。並且架構實際上也有種還原UML圖的意味，雖然工程量大，但難度上並不過高，甚至給了我一種再加把勁能夠本身寫出來個StarUML的錯覺（被打醒）。

PART5 總結本身在四個單元中測試理解與實踐的演進

　　簡直是哪壺不開提哪壺，丟人啊。看那個翻車的表情包我真是想笑又笑不出來。

　　第一單元測來測去，覆蓋性不足，撲街；第二單元，藉助別人寫的測試工具，好歹是測出了幾個重要的bug；第三單元，感受上沒問題了，但感受這個東西真的一點都不靠譜，想作一些測試，JML跑不了，想寫JUnit，發現本身不會用，根本上仍是測試不充分的問題；最後一個單元，迷信指導書樣例，忽略重要狀況。

　　由此就能夠看出一個要命的問題：覆蓋測試。這裏指的不是代碼的覆蓋，而是各類狀況的覆蓋，說白了就是多跑幾組不一樣的樣例。覆蓋測試充分的程序，bug就少或者沒有；沒怎麼進行充分測試的程序，bug就多得使人髮指。基本的功能測試和單純的邊界測試並不困難，但想要作到覆蓋測試卻很難，最難的一點，就是很難經過人力來進行覆蓋，測來測去總漏邊界狀況。關鍵是對於一個有bug的程序，它引起bug的邊界是不肯定的，這是我寫代碼的時候最最最最頭疼的一點。