BUAA-OO-U1-Summary

1 問題描述

​ 第一單元中，我們所要解決的問題是表示式化簡，即“去括號”。

​ 由於原表示式中可能出現乘方、自定義函式、三角函式、求和函式等形式以及相互之間的巢狀，因此，如何在去括號、函式帶入的同時保證形式的標準，並儘可能簡化結果，是需要解決的重點問題。

2 整體結構

​ 表示式化簡的過程總體來看就是一個字串讀取、解析、合併與化簡的過程。因此，我所建立的架構，由Lexer 、 Parser 、 Expression 、 Function 四部分組成，並在 MainClass 中相互作用得到結果。各部分的功能大致如下：

各部分間關係如下圖：

3 總體流程

首先進行自定義函式的讀取，並建立對應的 Function 類；

然後讀入初始字串，並利用 Function 類對其進行函式帶入；

利用處理後的字串建立 Lexer 類；

建立 Parser 類，對前一步建立的 Lexer 類進行解析並得到 Expression 類；

Expression 類對結果進行化簡後轉化為字串輸出。

4 迭代過程

三次作業中我的整體架構幾乎沒有改動，主要的變動為

• Term 以下增加了 TriFunc 類：

  ​ 第一次作業中我直接將 Term 利用 $term=a*x^b$ 的標準形式，將 Factor 直接識別為 Term 進行處理；第二次作業中，新增了 TriFunc 類，用 HashMap 容器儲存某一形式的三角函式對其指數的對映。

• 增加了與 Main 直接相關的 Function 類：

  ​ 第二次作業中，為了實現自定義函式的代入，新增了 Function 類，其作用主要為識別自定義函式的自變數並進行變數到函式串、函式串到主串間的字串替換；

4 分析

首先是類複雜度的分析：

其次是方法複雜度的分析：

可以看出，類和方法的整體複雜度均較低，複雜度高的主要是 Function 、 Expr 、 Parser 三個類，主要原因為：

• Function 類內需要實現兩個字串替換，同時還要利用棧進行括號匹配的比較，因此程式碼較長、複雜度較高；
• Expr 類內需要實現最高層的 toString() 方法，需要進行多種情況的判斷；
• Parser 類需要實現基元識別的 parseFactor 方法，由於基元形式較多，因此程式碼複雜度較高。

5 強測總結

​ 本單元實驗在強測中出現的僅有bug為第二次作業中，未實（發）現 sin() 和 cos() 內為常數的情況 實在想不到中測中竟然連一個這樣的資料都沒有 ，所以第二次作業直接爆炸，修改的話，直接將 Parser 中三角函式內部的表示式利用 ParseExpr 或 ParseTerm 進行解析 而不是解析power ，並在最後 toString() 時進行一個簡單的判斷即可。

​ 所以讀題還是很重要的...

6 互測總結

​ 本單元的互測自己出現的bug同上。

​ 對於互測，本單元中我並沒有使用資料生成器進行大範圍的評測，也沒有實現一個數據對其餘人均進行測試的評測機，因此互測積極性不夠強，只是根據房間內同學們的架構自行構建了幾個該架構中可能出現的問題，一一測試，太麻煩了。

​ 下週一定寫個評測機XP。

7 個人總結

​ 本單元的麻煩之處主要在於第一週整體架構的建立(同時要做pre)和第二週優化的實現，第三週的遞迴自定義函式其實可以很輕鬆的解決。

​ 而出現的bug主要是因為時間安排不當，最後一天才寫導致過於倉促，優化不完全，還出現了題目理解問題等這些本可以避免的問題。

​ 同時，測評機也是一個很方便的工具，懶得寫測評機會導致更大的麻煩，因此要主動尋找簡化工作的方法。