oo第一單元總結

oo第一單元總結

一.基於度量來分析本身的程序結構

1.第一次做業

思路：先判斷輸入格式，經過正負號切分，求導拼接。

statistic分析：

metrics複雜度分析：

類圖：

第一次做業代碼共208行，從互測組對比來看，代碼行數較少。基本複雜度爲1，說明代碼是結構化的，但圈複雜度和模塊設計複雜度都很是高，說明程序分支多，質量低，模塊間耦合度高，模塊難以隔離維護。我認爲形成這種狀況的緣由是在同一個函數中實現太多功能，而且只用了一個類致使的。

2.第二次做業

思路：將每一項分爲常數，x，sin(x)，cos(x)四個部分，分別記錄四個部分的指數，完成求導。

statistic分析：

metrics複雜度分析：

類圖：

第二次做業代碼共379行，初步嘗試應用多個類，代碼結構化程度下降，平均圈複雜度和模塊設計複雜度相比第一次做業都下降一些，但仍是很高，主要緣由是類的數量過少以及在我嘗試進行少量化簡的過程當中同一函數試圖完成的功能過多。

3.第三次做業

思路：將表達式拆分紅項，項拆分紅因子，遞歸求導。

statistic分析：

metrics複雜度分析：

類圖：

第三次做業代碼共653行，結構化程度低，平均圈複雜度和模塊設計複雜度相比第二次做業又下降一些，但仍然很複雜，沒有用到繼承和接口，主要就是將表達式拆分紅項，項拆分紅因子的遞歸思想。

二. 分析本身程序的bug

1.第一次做業

在互測中被找到一個bug，有關正則表達式，輸入

0*x^+0

個人程序輸出WRONG FORMAT!

緣由是判斷表達式格式時分爲其它項和第一項兩部分來匹配，先匹配除第一項外的其餘項，此時將+0看成一項，表達式格式錯誤。

改正：第一項前若無符號，在表達式前添加'+'，而後逐項匹配。

2.第二次做業

在互測中被找到2個bug，都是有關正則表達式，第一個是判斷四個符號相連錯誤時中間忘記加空格，即程序可接受++ ++1這樣的形式，第二個是因爲用了split('*')沒有判斷最後一個字符是否是'*'，因此程序可接受2*這樣的表達式。

3.第三次做業

在強測中被找到一個bug，在互測中被找到的也是同一個bug，緣由是沒有考慮到（）前有'-'的狀況，即輸入

-（x)

個人程序輸出WRONG FORMAT!

改正：合併修復，不在乎性能，將全部"-()"改成"-1*()"。

綜上：其實三次做業的錯誤都集中在正則表達式部分，與程序結構關係不是很大。

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

1. 看到長正則表達式，嘗試在限制長度內考慮會不會爆棧，第三次做業因爲添加嵌套結構，考慮套多層括號爆棧狀況。

2. 正則表達式部分：

   · 在不應加空格的地方加空格

   · 加負號

   · 第三次做業能夠嘗試各類嵌套

1. 分析代碼優化部分邏輯，由於中測中基本測試程序功能，因此優化部分更容易出錯。

   · 循環沒有及時跳出

   · 優化過程當中匹配的正則表達式，例如\d沒有加'+'

四. Applying Creational Pattern

個人三次做業對面向對象的思想都體現得不明顯，代碼擴展性差，沒法複用。並且徹底沒有考慮過三角函數部分的優化，只是簡單計算，致使性能低。

關於代碼重構，我首先是想實現求導接口，將各類因子創建類，實現求導接口。而後再考慮將求導接口與項和表達式創建聯繫。我如今對於接口的運用還不是很明白，還須要再想一想。

五. 有關面向對象和麪向過程的一點思考

由於我對面向對象的優點沒有實際體會，運用也不熟練，因此在閱讀第三次做業指導書後，我首先想到的是C語言數據結構中將表達式轉化爲後綴表達式，創建表達式二叉樹，自底向上求導。

將sin,cos,^,*,都視爲運算符，並給它們賦不一樣的優先級

程序類圖：

metrics複雜度分析：

我看到這道題的第二個想法就是遞歸，簡單應用接口後的程序,

類圖：

metrics複雜度分析:

個人第一種方法徹底沒有用到面向對象的方法，其中的Node類只起到結構的做用，經過複雜度分析，能夠看到圈複雜度和模塊設計複雜度在輸入格式檢查和創建表達式樹的幾個方法中很是高，其緣由是因爲後綴表達式會去掉括號，因此要在處理表達式以前進行sin(),cos()和（）^，幾個結構的括號檢查，而且在輸出以前還要再進行一遍括號的添加和刪減。

而在面向對象的設計中，能夠經過創建類和應用正則表達式的方法，使輸入格式檢查變得清晰。

第一種方法在創建表達式樹的過程當中，因爲自底向上的求導拼接形式，對於括號的把握也比較困難，而且形成圈複雜度很是高，讓程序的質量大大下降。

面向對象的編程能夠下降模塊間的耦合度，使程序結構化程度提升。