【面向對象】第一單元總結——表達式求導

基於度量的程序結構分析

第一次做業

類圖

代碼規模

代碼度量

「 ev(G)基本複雜度是用來衡量程序非結構化程度的，非結構成分下降了程序的質量，增長了代碼的維護難度，使程序難於理解。所以，基本複雜度高意味着非結構化程度高，難以模塊化和維護。實際上，消除了一個錯誤有時會引發其餘的錯誤。
  Iv(G)模塊設計複雜度是用來衡量模塊斷定結構，即模塊和其餘模塊的調用關係。軟件模塊設計複雜度高意味模塊耦合度高，這將致使模塊難於隔離、維護和複用。模塊設計複雜度是從模塊流程圖中移去那些不包含調用子模塊的斷定和循環結構後得出的圈複雜度，所以模塊設計複雜度不能大於圈複雜度，一般是遠小於圈複雜度。
  v(G)是用來衡量一個模塊斷定結構的複雜程度，數量上表現爲獨立路徑的條數，即合理的預防錯誤所需測試的最少路徑條數，圈複雜度大說明程序代碼可能質量低且難於測試和維護，經驗代表，程序的可能錯誤和高的圈複雜度有着很大關係。」
——引用自《OO課程中IDEA相關插件的使用》

第二次做業

類圖

代碼規模

代碼度量

第三次做業

類圖

代碼規模

代碼度量

優勢和缺點自我評價

個人優勢是程序結構構架地比較清晰，方法功能獨立，代碼中註釋寫得較爲明確；缺點是喜歡用較長的正則表達式，沒有對最後的輸出結果進行優化。

分析本身程序的Bug

本身的程序能夠較好地識別正確的，和有明顯錯誤的輸入內容，並正確地計算出結果。但遺憾的是對於一些非直觀的，相對於真實計算情境下非正常思路的輸入內容的識別力較差，好比+++2019這種類型的輸入，我在設計上沒有考慮到對這些狀況的包容，或者說，對於這類輸入的分析、解析沒有較好的設計思路。

分析他人程序的Bug的策略

在本單元的程序設計中，我主要採用瞭如下兩種方法去測試他人的程序：
· 根據本身在編程過程當中的思考和遇到的問題來對他人的程序進行測試。因爲每一個人的解題思路和程序構建思路是不一樣的，因此按照本身的程序邏輯流程能夠解決的輸入內容，不必定在他人的程序中也能夠順利解決。
· 我假定在進行下一階段的測試時，他所基於的以前的階段的代碼都已經通過充分測試，全部的迴歸測試都能經過，也就是說，程序中最禁受不住測試的地方是他根據新要求，進行改編的新代碼。那麼我會針對本次做業中的新要求的各類表現形式對他人的程序進行測試。

對象建立模式的應用

在本單元的三次做業中，我主要採用了工廠模式的對象建立方法。對Expression/Term/Factor的建立方法都是經過傳入字符串，返回一個相應的對象去完成，其中FactorX/.Sin/.Cos/.Const繼承於Factor父類。在方法調用上，他們對外的接口都基本只有.derivation() & .toString() 方法，分別返回他們加上括號的的導函數（String）和原始內容（String）。