OO第一單元總結——多項式求導

1、基於度量來分析本身的程序結構

1.第一次做業

UML類圖

 

 OO度量

 

此次做業我寫了3個類，其中class Struct是Polynomial的內部類，這個類有2個屬性：coe、index，分別表明每一個項的係數和指數；Polynomial類的構造方法用來判斷表達式是否合法，其餘的方法用來拆分項、求導、獲取coe和index，化簡、output結果表達式，Dx類用來調用Polynomial中的方法，完成程序功能。

2.第二次做業

 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這樣的化簡類型，因此程序性能不是很高。

 3.第三次做業

UML類圖

OO度量

感受此次做業的代碼結構仍是沒什麼太大變化，或者說沒有太OOP，依然是判斷合法性一個類，求導一個類（沒有優化），因爲此次做業的複雜度，致使我由於沒有重構使得個人代碼複雜度進一步上升。原本是想使用接口實現，奈何對於接口的使用不是很熟練，加上做業時間緊迫，最後仍是寫成了面向過程。

 

---

2、分析本身程序的bug

第一次做業的的bug在正則表達式這一塊，經過IDEA的調試，發現了正則表達式的括號使用不當致使匹配出錯。

第二次做業中，寫完程序後隨便輸入一個數據，控制檯就拋出異常，因爲IDEA調試的時候matcher.find()老是返回false，被坑了以後我一直覺得是正則出了bug，最後才發現是我判斷空字符串出錯了，查閱資料後發現字符串爲空有2種可能：

str == null || str.equals("")

 

第三次做業因爲嵌套的存在，正則表達式無能爲力，處理inputExpression的時候主要以字符爲單位去判斷，這裏佔據了我寫代碼的主要時間，在這塊，我是寫完這個模塊就開始測試輸入合法性，也是不斷的debug。而後求導那一塊我寫了幾個函數相互調用，經過層層遞歸來實現求導，這裏的bug主要是因子求導返回求導結果時的括號問題，如表達式因子求導返回的結果必須寫上外層括號。

個人感覺就是，當類以及類方法之間的耦合度太高，單個類方法代碼量過大時，程序的debug工做會變得很耗費時間，由於此時程序定位一個bug的範圍將變大，調試時會執行大量無心義代碼才能到達bug所在處，這將極大下降程序的維護度。

---

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

前兩次做業我主要是根據本身在寫代碼時構造的一些測試點來對別人的程序進行測試。

第三次做業因爲互測的要求，且程序的輸出各異，因此我利用對拍器來對他人的程序進行測試。

我會結合被測程序的代碼設計結構來設計測試用例，例如程序中使用的正則過長，那麼我會特別去分析它正則的bug。

---

4、Applying Creational Pattern

從這幾回做業能夠看出，當幾個類（如：三角函數、冪函數、常數）有相同的行爲特徵時，能夠採用Builder模式，定義一個接口來建立組合對象。

代碼重構的話，給3種因子分別建立一個類，去實現一個含有求導方法的接口，或者是去繼承一個抽象類，從而創建代碼的層次關係。