OO第一單元做業總結

oo第一單元的做業是對多項式的求導。下面就是對三次做業分別進行分析。

第一次做業

分析

第一次做業相對來說比較簡單，甚至不用面向對象的思想都能十分輕鬆的完成(實際上本身就沒有使用)，包含的內容只有常數項和指數項。實際上此次做業給個人最大收穫是初步認識了正則表達式的使用。程序的結構以下：

設計

結構十分簡單，只有一個類(就是面向了過程。。。)，類的構造函數用以處理輸入的字符串，calcDiff()用來計算導數。

度量分析

從表格中能夠看出來，factor()方法的複雜度與獨立路徑條數較高，這是由於這個方法中進行了太多的if-else判斷，代碼的分支條數太多，致使代碼可讀性不高。

強測

此次比較失誤的是沒有仔細審好題目，覺得++x這種操做是不合法。致使扣了必定的分數。

總結

本次做業難度不高，對於剛剛學java的菜鳥仍是十分友好的，但因爲對面向對象的思想仍是比較陌生，因此寫出來的代碼確實不忍直視。可是收穫仍是有的，好比學會了正則表達式等工具。

第二次做業

分析

此次做業明顯就要比上一次的做業難度上有了很大的提高。以及老師在週四的課堂上最後說了一句，「以爲第一次代碼寫的不行就趕忙重構吧，不然第三次做業是必定過不了的」。因而乎果斷重構了代碼。經過揣摩指導書(提醒了此次做業三角函數中只有x這種變量)，我提早預判到下次做業多是複合函數求導hhh，因此在構思的時候就把複合函數考慮了進來，在factor類裏增長了一個expression類型的私有屬性。

設計

UML圖以下：

與第一次做業相比，此次的設計要複雜的多，也有了面向對象的影子。

度量分析

此次有好幾個方法的V(G)值很高，一部分緣由是由於我考慮了factor中存在expression的因素，致使多了不少分支判斷。另外一部分緣由是由於在作輸出優化的時候沒有想清楚具體的優化方法，單純一味的if判斷。

總結

由於此次所設計的需求超過了實際需求，因此耗費了不少的時間，但也爲下次做業節省了很多時間。同時此次做業的測試規模已經十分之巨大了，因此我也學習了一下規模化規範測試的方法，用Junit進行了批量測試。

第三次做業

分析

實際上此次做業在發佈之初我就很是的興奮了，由於基本符合了我在做業二時所作的預判，總算沒有白費功夫。。因此實際上個人代碼結果和上次來說基本類似，花費的時間也比較短暫，一天就完成了這次做業。比較大的區別就是在於輸入判斷這塊，因爲factor裏面還有expression，這種帶括號的文法是沒法直接用正則表達式進行匹配的，因此個人解決方法是進行迭代處理。好比像sin((xcos(x)))這種Term，我是先將內部括號代換成x即sin(x)，以後判斷外層語法是否正確，而後在將(xcos(x))代換回來，等到factor內部的expression再進行判斷。

設計

UML圖以下：

整體思路和上次一毛同樣，就是修改了一些細節以及增長了一些用來優化的方法。

度量分析

總結

實際上個人這個設計上是有很大的缺陷的，實際上像加減乘除運算都應該從factor，term，expression類中抽離出來，單獨作一個運算類，高內聚，低偶和。而我如今所作的並無達到這一目的。因此每次修改一個類的方法都會致使一連串的連鎖反映，這也致使以後在強測的時候發現有一處判斷沒有修改而出現了錯誤。代碼的可讀性也差了不少。

Bug分析

三次做業的bug主要出現的位置就是在輸入處理和優化上面，輸入有審題不認真致使也有邊界考慮不周全致使。這部分的處理確實十分的棘手也很麻煩。只要思惟稍有不連慣性就頗有可能出現了bug。優化上的問題從根本上考慮就是設計上的缺陷致使，沒有很好的分析清楚各個類之間的繼承關係，致使每一個類內的書寫很是的累贅。

分析本身發現別人程序bug所採用的策略

實際上我沒有刻意的去挖掘他人的代碼缺陷並精心設計針對性的測試程序，仍是主要使用的黑盒來進行測試。在測試時，我編寫了一個自動生成測試用例的腳本(sympy進行驗證)，來測試代碼的正確性，會不會爆棧等。同時也人工設計了一些格式上有問題的數據來檢測程序的輸入處理上是否有問題。

Applying Creational Pattern

前兩次做業由於功能相對簡單，在沒有建立模式的概念下也能比較舒服的完成。但第三次做業的時候就感到十分不舒服了。若是要讓我重構的話，我以爲我會建立一個接口類以及常數類、三角函數類、表達式類、項類。用接口類給出不一樣的運算接口。而後再在每一個類中實現它。

總結

這三次做業作的確實都比較倉促，因爲還有別的一些事情，沒有花費足夠的時間在這上面，以後應該多花費時間在面向對象這門課來。

不過經過這三次做業，我對Java語言的掌握程度提高了不少，也對面向對象編程有了進一步的認識，逐漸擺脫了面向過程的思想。更加註重程序的可擴展性和魯棒性。