oo第一單元作業小結
在本次部落格的寫作中，我運用intellij旗艦版的diagrams功能繪製類圖，用metricsreloaded外掛程式進行**複雜度分析。
(1)基於度量來分析自己的程式結構
第一次作業
第一次作業的流程圖如下：
第一次作業的結構比較混亂，因為較少接觸物件導向語言的緣故，所以程式寫的一點也不物件導向，反而非常的面向過程，只設計了兩個類poly和term，連io這個類都沒有設計，而是選擇把io操作放在poly類的main方法中來實現，而且每個類的方法數也較少，每個方法的**數很長，難於維護，這樣的操作背離了物件導向的初衷。
第二次作業
。。。在第一次作業中學習了別人的**之後，第二次作業將io單獨列為乙個類，此外設立了poly、term、factor三個類，並且將方法細化，方法數增多了，每個方法的行數減少了，易於理解。
第三次作業
在第二次作業的基礎上，類的數目進一步增多，對字串的處理也單獨列為乙個類，程式越來越物件導向了。同時，由於沒有學會遞迴下降法，而是自己使用了乙個類似於遞迴下降法的方法用正規表示式寫出了程式，複雜度比較高。
(2)分析自己程式的bug
第一次作業
第乙個bug產生於對指導書沒有進行咬文嚼字的認真分析，誤以為「在本次作業中，空白符僅包括空格和\t」的意思是輸入的時候輸入的空白符只包含空格和\t，因此在正規表示式中只採用了\s作為匹配空白符，所以導致了\f這樣的隱藏空白符會產生程式bug，本應輸出wrong foramt!卻匹配正確。
第二個bug產生於對空串的理解不當，誤以為空串就是「」，所以用ctrl+z會炸我程式。
第三個bug產生於正規表示式的匹配方式，整體匹配是一種效能極差的匹配方式，字串稍微長一點就會爆棧。其實最有效的方法應採用逐項匹配，利用pattern和matcher類的find方法對字串分步解析，這樣對再多的項組成的字串也不會爆棧。
第二次作業
第二次作業的bug產生於各個類之間的資訊交流，有些類的字串是帶空白符的，有些沒帶，把poly類的字串傳遞給term類時因為空格的問題產生不相容。
第三次作業
第三次作業的bug產生於對符號的處理，由於在factor類中的求導結果會產生-號，在有多個-號時會使程式產生錯誤。
(3)分析自己發現別人程式bug所採用的策略
在發現別人的bug時，我首先觀察了別人引入了什麼包。例如引入了arraylist我就知道他是利用了arraylist這樣的資料結構來訪問資料，引入了hashmap我就知道他是利用了hashmap這樣的資料結構來訪問資料。有的程式沒有引入biginteger,我就輸入乙個超出了long,int等基本資料型別表示範圍的字串，成功刀到人。對別人的程式採取覆蓋性測試，如果實在做不到就盡量多對邊界資料進行測試，因為一般的資料肯定刀不到人，所以盡量輸入特殊的資料，例如+++1，+++ 1這些非常特殊的資料。
通過第一單元的學習，我對物件導向有了較為清楚的認識，知道面向過程與物件導向的區別，思維也從面向過程逐漸過渡到物件導向。編寫工程**不能再像以前一樣想到哪寫到哪，在編寫**時前要構思好程式的設計框架，可以先把各個類的名稱，方法名寫出來，寫完之後再寫具體實現。除此之外完備的測試樣例也是極為重要的。
通過互測，不僅可以增強自己發現bug的能力，還可以從別人的**中學到很多東西。例如我從別人的第一次作業中學到了如何物件導向，從別人的第二次作業中學到了繼承與介面，從別人的第三次作業中學到了遞迴下降法的詞法分析。這樣對我的程式設計能力是極大的提公升。
北航oo作業第一單元小結
前言 在經過了三次艱辛的oo作業後，oo課程的第一單元告一段落，這一單元，我作為乙個oo小白，開始了解oo的程式設計思想，也有了自己的一點心得體會。把筆粗成字，不當之處，還請各位大佬多多指教。一.分析程式結構 第一次作業 在第一次作業中，由於剛剛開始接觸oo的思想，我還不是很了解物件導向的程式設計方...
OO第一單元作業總結
1.第一次作業 第一次作業時我還沒有建造者模式這種概念，因此是把字串處理的工作交給expr類來處理，在expr類中呼叫term的構造方法，並將term的係數與指數存放在expr的容器中。類圖如下 結構比較的簡單 下面是複雜度分析 可以看出，在expr的求導操作中複雜度較高，這是因為我第一次作業中求導...
oo第一單元作業總結
雖說後一次作業是對前一次作業的擴充，然而由於我不太熟悉面對物件程式設計的思想，程式的可擴充性極差，致使三次作業三種架構，異常愚蠢。設計思路 受上機實驗 啟發，用兩個數 係數和指數來表示一項，用項組成的表來表示項之間的加法關係。通過對表示式符號的簡化，得到了更符合一般形式的輸入，但背離了題目中的構造思...