1. 程式人生 > 其它 >OO第一單元總結部落格

OO第一單元總結部落格

1.第一次作業

1.1思路分析

第一次作業主要任務是完成對錶達式的去括號,在完成第一次訓練的作業後使用梯度下降法分析表示式,將表示式,項,因子逐層分離。在完成表示式轉換為各項因子後,難點就在於項與項之間的相乘以及符號的轉化,表示式之間的因子用+,—號連線,而項之間因為可能又存在表示式的因子無法之間*連線。符號的問題,我在表示式的項連線時統一用+號,並給所有實現了因子類的介面增加了一個正負的屬性,用於記錄因子在最終表示式的正負,而相乘的問題我採用遞迴的方式來解決。

1.2結構分析


本次作業中類圖如上,Expr,Term,Number,Power為實現了Factor的因子類,在梯度下降分析時儲存資訊,Lexer,Parser為梯度下降所使用的類,是實現梯度下降分析的工具。Multiplier類是用於項與項相乘時,採用遞迴方法進行相乘的類,是實現括號展開的工具。Organizer和Monomial是最後用於簡化的類,在返回了展開的字串後,將為簡化的字串經由Organizer遍歷,拆解為單項式Monomial進行整合化簡。

度量分析



許多方法複雜度較高,結構化程度低,耦合也很明顯

1.3bug分析

本次作業bug主要為符號問題,對複雜表示式處理時符號的正負經常出錯,在bug修復階段找出了問題所在並進行了修復,在本次互測階段,我才用隨機資料的生成進行hack,與我同一互測房的同學們也在正負號處理上出現了問題。

1.4感想與收穫

本次作業中最大的收穫是對梯度下降法的學習與應用。在寫作業之前對java的學習還停留在較淺的階段,在作業中遇到不少與java相關的困難,在查閱資料解決後,對java有了更深的理解並且初步認識了OO的思想。

2.第二次作業

2.1思路分析

相比與第一次作業,第二次作業在表示式中增加了自定義函式與sum函式以及三角函式。在第一次作業的基礎上,我採用了字串替換的方法,將表示式中自定義函式與sum函式在梯度下降分析之前轉換為表示式因子,新建三角函式因子類。這樣就可以用第一次作業的構造處理表達式。然而也會引出許多問題。首先就是這樣會造成多層括號的巢狀,梯度下降法本身便支援多層括號的分析,而我在處理表達式與項的展開時採用遞迴的方法,在對第一次作業的Multiplier類進行改進後便可以處理多層括號。其次,字串替換過程也不被老師所提倡,一是不符合結構化層次的要求,二是字串替換過程中可能會造成許多bug,在編寫完成測試時便發現了在字串替換過程中正則表示式造成的bug,然而仍有bug未找出來導致強測錯了部分點。

2.2結構分析


本次作業相比與第一次作業增加了Trigonometric類,在梯度下降時用於儲存和分析三角函式的類。增加了Replacefun類,用於在字串輸入後,梯度下降之前,對自定義函式進行字串替換,而sum函式在lexer類中字串輸入後的預處理中替換。增加了MonomialTri類用於在字串結果化簡時,儲存和分析每個單項式中的三角函式。

度量分析


與第一次作業相比,上次複雜度較高的方法並沒有加以簡化,並且因為第二次作業需要,複雜度更加高了,耦合度也更高,沒有很好地運用層次化結構地思想

2.3bug分析

本次作業地bug正如前文所述,在表示式地字串替換時產生了許多bug,如字串替換時,正則表示式地缺漏,導致沒有捕捉到本該替換的字串導致的bug,字串替換時新增括號的問題,正負號問題,sum函式中i的替換與sin函式產生的衝突,以及替換時的位置問題,都十分容易出錯而導致bug,在本次作業強側中,便是對sum函式捕捉的正則表示式缺漏,導致沒有替換而產生的bug,在互測中,採用字串替換的同學,或多或少可能都在正則表示式以及替換策略亦或是替換細節有某些小bug,而採用老師推薦的方法(將函式視為因子建模)的同學便很少有bug。

2.4感想與收穫

因為自己採用了老師所不推薦的方式解析表示式不僅破壞了程式的層次性也造成了許多bug,可能也會導致後續的迭代開發中的諸多困難。還需要學習體會層次化結構設計以及面向物件的思想,才能寫出更具有魯棒性,易維護,易讀的程式碼。

3.第三次作業

3.1思路分析

本次作業相比於第二次作業增加了函式的巢狀呼叫,三角函式內因子可以為表示式因子,以及多層括號的處理。多層括號的處理。在第二次作業所採取的策略已經支援了多層括號處理,三角函式內的因子在梯度下降解析是便以表示式的形式儲存,在輸出是直接將三角函式內的表示式轉換為字串輸出便可,而函式的巢狀呼叫,在做函式字串替換時,對於作為替換者的字串,再遞迴做函式的字串替換。相比於第二次作業而言,增加的要求不多。

3.2結構分析


本次作業相較於上次,沒有增加新的類,只是在原有的類中進行了一些方法的修改以及方法的增添,沒有實現新的功能,只是更改某些方法使得可以遞迴呼叫。

度量分析

本次作業是本單元最後一次作業,在此基礎上看此架構。許多方法邏輯過於複雜,耦合度較高,類與類之間的層次關係不明顯,沒有很好的結構化特徵。

3.3bug分析

因為直接在上一次基礎上遞迴呼叫函式,原來的字串替換導致的bug都已解決。而此次bug的問題在於三角函式內巢狀某些表示式因子時沒有加一層括號,以及sum函式上下限的取值超過int時的問題。是一些細節上的錯誤,以及對問題的思考不夠全面。而在互測中,同學們也大多產生了sum函式上下限超過int時而產生的bug。

3.4感想與收穫

本次作業相較於第二次,增加的要求不多,然而在第三次作業中的bug是第二次作業中就有的了,而在第二次作業中強測,互測以及自己測試中都沒有發現。測試無法說明自己的程式碼沒有bug,即使過了中強測也要自己多多測試,以發現在測試中未能發現的bug

4.心得體會

第一單元是面向物件程式設計的開始,讓我對面向物件的程式設計思想有了一個很好的瞭解。在這一個單元的三次程式設計作業中,我開始明白麵向物件程式設計與面向過程程式設計的區別。面向物件程式設計,是把程式的工作看作是不同類之間的相互協作和相互呼叫,通過建立不同的相對獨立的類,使得它們之間進行互動的同時又保留一定的獨立性,降低程式的耦合性,提高程式的可擴充套件性。面向物件和麵向過程兩種程式設計方法,沒有一定的誰比誰更好,只是在面對不同的問題時各有優劣。在本單元作業中,我的設計並不是很好,拓展性也不是很好,而第三次作業所增內容不多才讓我得以不用重構。對面向物件的程式設計思想,層次化的分析還不能很好的運用在程式設計設計中。