面向對象第一單元總結

前言

　　從接觸OO課程至今，我已經完成了三次OO的關於表達式求導的做業，也是時候對本身的編程做業進行一次總結了。鑑於三次做業從指導書上描述差異不大，所以將主要針對第三次關於表達式求導的代碼進行分析。

程序結構的分析

對程序架構的描述：

　　對於OO（即面向對象編程），我目前爲止一直採起的策略是儘量地對目標進行封裝，但鑑於一，二兩次做業並無多大地工程量，所以我並無採起嚴格地分類，即輸入類，輸出類，sin類等的分類方式，第一次做業只有一個類，而第二次也只分了Expressioninput，ExpressionProcess，ItemProcess和Poly四個類，從類的命名能夠看出，我分類的思路並非對一個單純的物體對象進行封裝，我封裝的對象是一個過程，這其實源於我對面向對象的理解。我認爲的OO強調的是一個類只須要給與和給出信息，就算合格，可是不少時候，給出的信息也須要統合才能真正起到做用，就好像火箭的每一個模塊都造好了，但仍須要一條流水線來完成火箭的組裝同樣，而流水線自己也能夠做爲一個對象進行封裝，這就是我前兩次做業的架構思想。而第三次做業隨着難度的增長，我在封裝流水線的基礎上進一步細化，以下圖。

　　從上圖，我細化了封裝的求導部分，拆解成單獨的加法式（包含在Inputcheck類裏），乘法式，括號式，以及各種通常因子的處理，整體上對類分劃分我的仍是比較滿意，但問題出在加法式處理這一部分，從上圖（Statics插件分析的結果）看，很明顯Inputcheck這一負責處理輸入格式問題的類行數遠多於其它類，形成這一現象的緣由是，我把加法式類寫在了這個類裏面，正確的作法應該是採用繼承，或類的聲明與調用。此外，加法式類徹底與其餘類脫節，致使其內含有大量的雜碎功能，包括但不限於格式的檢驗，括號的匹配，這樣的設計是徹底違背封裝的初衷的。

經典的OO度量

　　採用了IDEA的插件Metricsreloaded對第三次做業計算經典OO度量，結果以下圖：

　　從上圖，能夠看出我在第一部分對Inputcheck的分析是徹底正確的，Inputcheck內這幾個重要方法，基本複雜度高，模塊設計複雜，與其餘模塊的耦合度高，並且難於獨立地進行檢查和維護，能夠說至關的失敗。而各種的方法廣泛具備結構化較差的缺點，據我分析，緣由是我沒有采用繼承，由父節點負責相同的方法，而是對每一個相似的類都手動copy了一個相似的方法，模塊化低下，難以維護。

程序類圖

 

 　　優勢：

1. 1. 基本對不一樣對象進行了完全封裝。
   2. 實現了經過不一樣類之間的調用完成降層的求導過程
   3. 採用繼承，實現了常量的屢次複用

　　 缺點：

1. 1. 沒有徹底正確地設計類的種類，例如加法式類被寫成了Inputcheck的一個方法
   2. 繼承沒有正確運用，其價值不只在繼承常量，還在方法的複用
   3. 方法沒有正確構建，方法之間存在重複

分析BUG

　　目前爲止的三次做業，第一次在強測和互測環節均未出現BUG，下面以第二次和第三次作分析。

• 第二次做業

　　輸入示例：

 

x*sin(x)*cos(x)-+-2*x^-3*sin(x)^-2*cos(x)^+3

 

　　個人錯誤輸出：

x*cos(x)^2-x*sin(x)^2+sin(x)*cos(x)-6*x^-3*sin(x)^-cos(x)^2-4*x^-3*sin(x)^-3*cos(x)^4-6*x^-4*sin(x)^-2*cos(x)^3

　　很明顯，個人錯誤是輸出地部份內容莫名其妙地消失了，在BUG修復階段我從新審查了程序，發現錯誤在這裏

                temp = temp.replaceFirst("-1\\*","-");

　　這段代碼本意是將每一項開始係數爲「-1*」的部分省略爲「-」，可是，在實際操做過程當中它的實際效果是將第一個匹配到的「-1*」省略爲「-」，修改成以下便可，出現這個問題主要是沒有很好的明白得到信息和要求的信息具體條件是什麼。

                temp = temp.replaceFirst("^-1\\*","-");

 

• 第三次做業

 

1. 輸入示例：　

cos(    (-sin    (((0)+0))))*    sin(100000000)    +    cos    ((x*    00000)    )

　　 2. 輸入示例:　　

cos((cos(sin(x^3)^3)^3))^2*x^1*sin(x^2)^1

　　以上輸入個人程序都會給出」WRONG FORMAT!「的錯誤輸出，細察其緣由，問題出在Inputcheck類中的special方法上，該方法設計的初衷是爲了全覆蓋檢測"sin()"、"cos()"內的括號內容是否合法，但在實際設計的時候並無將全部的可能涵蓋在內，屬於設計不全面形成的BUG。勉強能夠和設計的重複性致使的設計思路混亂扯上關係，不過，歸根結底，應該是設計的不完善形成的。

　　爲了解決這個BUG產生的根源，應作好完善的設計檔案，至少，針對須要完備性設計的程序塊要有一個清晰的設計，以便審覈全覆蓋與否。

分析別人BUG的策略

1. 使用本身的測試集測試；
2. 分析指導書，進一步尋找可能的邊界條件，構建測試樣例測試
3. 對代碼進行分析，針對性寫測試樣例

 總結和反思

　　個人第一次、第二次和第三次做業都是徹底獨立的，即沒有采用重構的方式，主要緣由仍是第一次和第二次重構的代價太大。第一次做業徹底只有一個類，不具有重構的價值；第二次做業與其說是面向對象的思路，不如說是面向流水線的拼接思路，本質上走的仍是順序編程的思路，一樣沒有重構的價值。第三次做業，將分別封裝獨特的類，已經具有了重構和繼承的基礎，在第三次做業的基礎上能夠繼續添加條件和要求。對針對性的類，好比對乘法的拆解，徹底能夠採用繼承的方式，添加須要增長的因子，或者採用重構，更改拆解的方式和格式。可是，由於加法式的拆解內嵌在了Inputcheck裏面，對它的重構可能會出現不可預料的結果，所以，若是不更改Inputcheck的結構，重鑄加法式類，那麼最好採用繼承的方式重寫。