物件導向第一單元個人總結

2022-10-09 05:57:07 字數 3324 閱讀 7231

第一次作業我依託訓練的**進行自己的構造,主要有三個部分:輸入轉換、表示式解析以及結果的計算與輸出。其中,對於表示式的解析結果,我使用字尾表示式進行儲存,以方便計算。此時,傳入到最後一部分的就只有一串字元,滿足低耦合的要求。整體上,使用training的語法分析模式,設計processor類進行文法提取,並協助parser進行語法分析。

expressioncheck清除輸入中的空白字元。

factor代表因子,儲存了常數與x,以及他們的各種屬性:指數、正負、絕對值等。此處融合在一起,雖然寫起來方便,但不如構建新類繼承父類的實現方式那樣有良好的拓展性與可讀性。因此,後面作業時對此處有較多修改。

parser、processor、expression、term、general等都用來進行表示式的解析,同時參考training實現了遞迴解析。表示式的層次關係也主要依靠這些類實現。

calunit中用biginteger[8]記錄各項,並實現了加法、乘法的運算,用來進行最後的運算。

遞迴下降滿足多括號需求、整體思路明確、用陣列計算簡便、易於理解。

factor類的可拓展性不高,同時calunit中儲存單元的拓展性也很弱。在之後的作業中需要修改。

從上圖中,可以看見整體複雜度與類的耦合度都較低,主要是字串處理與判斷時,相關方法的複雜度、相關類的非結構化程度較高。

針對前置正負號、0次方、大數範圍等形式化表述中易錯的點構造測試點,以及自身完成作業時的一些易錯例子,進行互測。最終,用前置正負號成功地hack了乙個人。

此次作業未發現bug,但效能需要提公升,如x**2與正數前置。

第二次作業相比於第一次作業增添了三角函式因子,以及自定義函式和求和函式。因為我認為我第一次作業解析較好,所以此次作業中我採用字串替換的方法處理自定義函式以及求和函式,在替換時對替換部分兩端填一層括號以滿足表示式的層次要求。替換在讀取到表示式後便進行操作。這樣的做法雖然簡單,但很容易出錯。因此,此次作業的bug較多,強測只通過了七個點。

trifunction繼承factor類,代表三角函式因子,但其餘兩種因子仍聚在factor中,這也是我設計中不好的地方,導致factor類過於臃腫,複雜度較高。

calunit類中儲存單元我採用了hashmap,biginteger>的形式,以滿足多因子的表達形式。每乙個hashmap中只用*運算,外部雜湊的每一項用+運算。

遞迴下降滿足多括號需求、字串替換簡單、符合人類運算思路,儲存單元。

字串替換的方法很容易產生bug,儲存結構較為複雜、進行運算時容易出錯,在化簡上拓展性弱。

針對三角函式解析、次方解析與運算等形式化表述中易錯的點構造測試點,以及自身完成作業時的一些易錯例子,進行互測。最終,用三角函式解析:(sin(x) + cos(1)) * (sin(x)- cos(1))  與  (sin(x)+cos(1))** +02   成功地hack了6次。

此次作業bug較多,主要是三角函式解析和求和函式解析時未考慮帶符號整數情況,在字串替換時導致內部混亂,無法解析。此外,還有指數解析未考慮+號以及0次方的情況。本次作業情況很糟糕,原因是未進行充分的測試以及貪圖簡單使用字串替換。 

第三次作業與第二次作業的構造基本相同,主要是改變了三角函式trifunction類中因子的資料型別,由factor變為expression,可以在內部解析表示式而非簡單的變數、常數因子。同時,函式的相互呼叫我採取的辦法是:在字串替換時,進行多次查詢替換,直到不再有自定義函式和求和函式。增添了檢查三角函式內因子是否需要增減括號以滿足形式化表述與效能優化的方法。

有簡單的優化處理、遞迴下降滿足多括號需求、整體思路明確、在上一次作業的基礎上修改較少,只需呼叫方法。

字串替換的方法很容易考慮不周,產生許多小bug,儲存結構較為複雜、進行運算時容易出錯,化簡效能差,**結構冗雜、拓展性差。

從上圖中,可以看見與第二作業類似更複雜的字串替換引起更多的判斷進而導致整體複雜度再次上公升。方法上檢查三角函式、計算等字串處理判斷方法的複雜度仍較高、相關類的非結構化程度較高,mainclass不夠簡潔。

針對三角函式解析、資料範圍等形式化表述中易錯的點構造測試點,以及自身完成作業時的一些易錯例子,進行互測。最終,用三角函式解析:sin(+0)+cos(sin(0)) 與用資料範圍:sum(i,111111111111111,111111111111111,x) 成功地hack了2次。

此次作業bug相比上次明顯減少,強測有三個點沒過,主要是求和函式的資料範圍以及字串替換時的考慮不周導致內部混亂,無法解析。原因是未仔細閱讀指導書以及未經過充分測試。

第一次作業由於對設計思想不熟悉,導致依靠training進行架構設計,未理解將因子用類分開的好處,導致**冗雜,僥倖通關。

第二次作業採取了不好的字串替換方法,增添了自定義函式解析類以及繼承factor的三角函式因子類。不好的方法刀子需要考慮的情況很多,進而引起一系列小bug,如正負號、指數的解析。第二次作業整體架構還好,遞迴下降使得只需新增一些類便可滿足要求。可見好的架構是乙個專案的基礎。

第三次作業是比較輕鬆的,由於第二次架構的完整性與拓展性,第三次作業中僅改變三角函式trifunction類中因子的資料型別、增添了三角函式優化方法便完成了作業,再次證明了好的建構的重要性。從第二次作業的慘淡結果看,良好的方法選擇也是必不可少的,否則會出現許多意想不到的情況。

第一次接觸物件導向程式設計,很不熟悉,幾乎沒有思路,借助training的幫助才懂得了一些,有了初步思路。在第一單元的學習收穫頗豐,類似繼承、介面等方法,以及一些容器的選擇使用。與此同時,幾次作業的結果讓我明白了測試的重要性,測試的付出與最終的結果成正比,這是我這一單元得到的最大教訓。另外,寫**不能想著偷懶,選擇不合適的方法,否則bug會從各種各樣的地方冒出來。本單元深化了我對工程化思維的認識,並期待在今後能夠做得更好,不要再犯第一單元的錯誤。

OO第一單元總結

由以上類圖,大體分析本次作業程式設計思路如下 2 根據資料度量分析程式結構 那麼根據以上引數含義,分析本次作業 發現,有三個方法的這三個複雜度較高,分別是ploynomial.getpoly readterm.getnum readterm.getterm 所以可以知道本次程式分別在讀入操作和獲得表...

BUAAOO第一單元總結

第一單元的作業是對多項式求導,三次作業分別完成了簡單冪函式表示式求導 帶簡單巢狀的表示式求導和三角函式求導 豐富巢狀的表示式求導及格式檢查。本人在第一次作業中使用的是正規表示式匹配和字串預處理相結合的方法,可以達到需要的效果,但是越過了格式約束並降低了可擴充套件性,導致第二次作業不得不重構。第二次作...

OO第一單元總結

第一單元的作業為多項式求導,在迭代作業中學習了 物件特性 oo構造機制和層次化設計,在bug互測環節也學習到很多巧妙的設計。設計了三個類 term derivative和reportexit,分別處理項 求導和報錯退出,如今回頭看有很多設計不合理的地方,例如在term構造方法中直接解析表示式並設定成...