uml類圖
oo度量
這次作業我寫了3個類，其中class struct是polynomial的內部類，這個類有2個屬性：coe、index，分別代表每個項的係數和指數；polynomial類的構造方法用來判斷表示式是否合法，其他的方法用來拆分項、求導、獲取coe和index，化簡、output結果表示式，dx類用來呼叫polynomial中的方法，完成程式功能。
uml類圖
oo度量
從uml類圖中看出，這次作業將許多程式功能都放在的乙個類expdeal裡面，這樣明顯不利於程式的維護，也不利於找bug，還有expdeal類裡面的方法的複雜度也很高，根據生成的complexity**看,expdeal.indexspilt（獲取每個項的x、sin(x)、cos(x)的指數）和expdeal.prin_exp1（輸出求導後的表示式）的iv(g)（表示乙個方法和他所呼叫的其他方法的緊密程度）和v(g)（迴圈複雜度）都很大，再就是這次作業由於沒有找到很好的優化方法，僅僅處理了sin(x)^2+cos(x)^2=1這樣的化簡型別，所以程式效能不是很高。
uml類圖
oo度量
感覺這次作業的**結構還是沒什麼太大變化，或者說沒有太oop，依然是判斷合法性乙個類，求導乙個類（沒有優化），由於這次作業的複雜度，導致我因為沒有重構使得我的**複雜度進一步上公升。本來是想使用介面實現，奈何對於介面的使用不是很熟練，加上作業時間緊迫，最後還是寫成了面向過程。
第一次作業的的bug在正規表示式這一塊，通過idea的除錯，發現了正規表示式的括號使用不當導致匹配出錯。
第二次作業中，寫完程式後隨便輸入乙個資料，控制台就丟擲異常，由於idea除錯的時候matcher.find()總是返回false，被坑了之後我一直以為是正則出了bug，最後才發現是我判斷空字串出錯了，查閱資料後發現字串為空有2種可能：
str == null || str.equals("")第三次作業由於巢狀的存在，正規表示式無能為力，處理inputexpression的時候主要以字元為單位去判斷，這裡佔據了我寫**的主要時間，在這塊，我是寫完這個模組就開始測試輸入合法性，也是不斷的debug。然後求導那一塊我寫了幾個函式相互呼叫，通過層層遞迴來實現求導，這裡的bug主要是因子求導返回求導結果時的括號問題，如表示式因子求導返回的結果必須寫上外層括號。
我的感受就是，當類以及類方法之間的耦合度過高，單個類方法**量過大時，程式的debug工作會變得很耗費時間，因為此時程式定位乙個bug的範圍將變大，除錯時會執行大量無意義**才能到達bug所在處，這將極大降低程式的維護度。
前兩次作業我主要是根據自己在寫**時構造的一些測試點來對別人的程式進行測試。
第三次作業由於互測的要求，且程式的輸出各異，所以我利用對拍器來對他人的程式進行測試。
我會結合被測程式的**設計結構來設計測試用例，例如程式中使用的正則過長，那麼我會特別去分析它正則的bug。
從這幾次作業可以看出，當幾個類（如：三角函式、冪函式、常數）有相同的行為特徵時，可以採用builder模式，定義乙個介面來建立組合物件。
**重構的話，給3種因子分別建立乙個類，去實現乙個含有求導方法的介面，或者是去繼承乙個抽象類，從而建立**的層次關係。
OO第一單元總結 表示式求導
三次作業的內容均為多項式求導。第一次僅有冪函式，第二次新增了三角函式，第三次增加了巢狀因子。在格式輸入和計算過程中，前兩次都有較為固定統一的格式，而第三次由於有巢狀的遞迴表達，如果前兩次沒有專注設計 淚目 則需要尤其調整結構的問題。整個問題可以被拆分為格式檢查 求導計算和輸出處理三部分。其中格式檢查...
OO第一單元總結
由以上類圖，大體分析本次作業程式設計思路如下 2 根據資料度量分析程式結構 那麼根據以上引數含義，分析本次作業 發現，有三個方法的這三個複雜度較高，分別是ploynomial.getpoly readterm.getnum readterm.getterm 所以可以知道本次程式分別在讀入操作和獲得表...
OO第一單元總結
第一單元的作業為多項式求導，在迭代作業中學習了 物件特性 oo構造機制和層次化設計，在bug互測環節也學習到很多巧妙的設計。設計了三個類 term derivative和reportexit，分別處理項 求導和報錯退出，如今回頭看有很多設計不合理的地方，例如在term構造方法中直接解析表示式並設定成...