OO_JAVA_表達式求導_單元總結

OO_JAVA_表達式求導_單元總結

這裏引用個連接，是我寫的另外一份博客，講的是設計層面的問題，下面主要是對本身代碼的單元總結。

程序分析

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

第一次做業

程序結構大體如圖：

結構比較簡單，只有三個類，分別是Main，Polynomial和PolynomialItem。

方法複雜度分析如圖：

能夠見得：主要是類的構造方法和toString方法複雜度較高，由於要面面俱到。

第二次做業

程序結構大體如圖：

程序結構比較簡單，只有六個類。

方法複雜度如圖：

能夠見得：因爲是在表達式和因子的類以外創建的求導方法類，Diff類的求導和化簡函數複雜度都很高；而後就是因子Factor的構造方法和toString方法以及Item的構造方法複雜度很高；再其他就是ExprProcess處理類複雜度很高。

Diff類和ExprProcess類內部都是靜態方法，這樣設計是來自過程式編程，採起一個函數處理不須要本身獨立的屬性，即不須要創建一個類，直接使用其靜態方法，靜態方法其主要工程用途應該是做爲工廠函數，如此寫做是濫用，我已經意識到了。

第三次做業

程序結構大體如圖：

這張圖代表，Atom與其子類是關係緊密的，其它在邏輯上較爲分離的。

全部的Atom子類都繼承自Atom父類，這在設計上是不可取的，依賴度過高，不該該是extends繼承的真正用法。

Atom父類包含了全部子類所需屬性和方法，也不合理。

方法複雜度如圖：

首先列舉一下複雜度較高都是些什麼方法：

1. ExprProcess靜態方法類，因爲依舊是與第二次做業類同的組合方式，寫出了這麼個靜態方法類，形成了單一方法巨大的複雜度，應該按照我在我開頭引用的個人博客連接裏的Parser的寫做方法，把複雜度分散到不一樣Parser接口實現中，可是這基本上是我第三次做業寫完了才學到的方法，因此沒有運用；
2. AtomFactory類的兩個靜態方法，這是我爲了集約式根據枚舉類型建立子類而編寫的，複雜度高情有可原；
3. PlusAtom和MultiAtom的Merge方法，由於處在合併同類項層次，故而要處理的類不少，因此複雜度極高，是屬於能夠拆分的；
4. Atom類內部一系列跟合併化簡相關的函數，由於其寫做在頂層父類Atom中，又牽涉各級子類，複雜度較高：
   • couldBeMergedAroundPlus和couldBeMergedAroundMulti兩個函數，個人Predicate接口，用來判斷兩項是否能被合併，尚未有效的構建方式，涉及子類有比較多，因此複雜度高；
   • equals方法：爲上述兩個函數準備的，依舊是處於父類，因此方法複雜度較高；
   • expand和flatMap方法：依舊是爲化簡準備的，可是寫在父類，不可避免地發生了比較高的複雜度。

(2)分析本身程序的bug

表達式求導的第一次做業比較簡單，中強測和互測沒有叮出bug；

第二次做業的bug問題主要是縮略空白字符時，正則表達式漏了+號表示替換一片空白爲一個空格，所以出了正確格式誤判爲WF；

第三次做業優化部分有很大的bug，除此以外，在正常處理部分，漏算了一條Scanner的hasNext方法會略去最後的空白字符，應該提早trim掉，改了這個bug並刪去優化的調用，就修完了，也就是說正常處理部分是這一個bug。

整體來講最容易出現bug的位置仍是輸入處理和優化這兩部分，輸入是業界老大難，畢竟很難保證用戶不會某一個異常輸入爆掉你的程序，因此這部分處理因爲思惟的侷限性、不連貫性，很容易出現疏漏，而優化部分，很容易由於過於複雜的邏輯產生代碼中的隱蔽問題，可能簡單的樣例沒有問題，可是稍微精心的樣例就能夠爆掉。。

這就說明，邏輯越內秉，越聚合在一塊兒，就越容易出現bug，輸入處理和優化都是這樣。

因此設計類、接口的層次結構時就必須考慮這個問題，分散邏輯。

從樹的角度，我設計的類有個很大的問題就是父類實現了全部的方法，太累贅太複雜了。。。

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

我沒有采起研究別人代碼或是正則的方式尋找bug，屬於隨心隨機地寫一些數據找別人的bug，由於第二次做業犯了小錯誤，第三次做業交了優化版本還有其它的小疏漏，應該是被分到C組這樣，因此隨機地構造一些數據我就找到了不少別人的bug，可是第一次做業就不行了，在結構很是簡單的前提下，要找bug就必須深刻細節或者是大批量測試才行。

個人主要隨機構造思路就是儘量嵌套多一些，空格隨機加一些，主力尋找別人把正確格式誤判爲錯誤格式這樣的bug。

(4)Applying Creational Pattern

前兩次做業因爲類的數目在設計上就比較稀少，第一次3個，第二次6個，在編程上並無學會或者是意識到要運用什麼設計模式；

可是第三次做業達到了空前的突破，達到了17個類，這時我也意識到了工廠方法，能夠更加靈活地建立對象，並私有化構造器，若是如今讓我設計，第三次做業的表達式樹部分的類，我必定會採用統必定義接口的方式，實現接口的類都添加工廠方法，以此來梳理結構，減輕父類甚至去除父類。