一、基于度量對程序結(jié)構(gòu)的分析

1. 第一次作業(yè)

1.1 基于類的分析的度量

首先，基于類的屬性個數(shù)，方法個數(shù)，每個方法的規(guī)模，每個方法的控制分支數(shù)目，類總代碼規(guī)模等特征對本次作業(yè)的結(jié)構(gòu)進行分析。

1.2 基于類間內(nèi)聚和耦合的度量

我使用了MetricsReloaded插件來對代碼的復(fù)雜度進行了分析。

還有對于方法的復(fù)雜度分析由于篇幅原因沒有貼出來，主要的指標(biāo)為ev,iv,v三個指標(biāo)，分別代表基本復(fù)雜度、模塊設(shè)計復(fù)雜度以及模塊判定結(jié)構(gòu)復(fù)雜度，ev大代表代碼非結(jié)構(gòu)化程度高，難以模塊化和維護。iv大代表模塊間耦合度高，模塊間難以隔離與復(fù)用，v大表示代碼獨立路徑條數(shù)多，難于測試和維護。在做面向?qū)ο蠖攘繒r，我們經(jīng)常采用ck度量(Chidamber Kemerer)來度量耦合，內(nèi)聚，封裝等等特征。上表中wmc代表的是類的方法權(quán)重，表示一個類中所有方法的復(fù)雜度之和。顯然越大說明越復(fù)雜。

1.3 UML圖及結(jié)構(gòu)點評

由于是第一次作業(yè)，因此對于面向?qū)ο蟮乃枷脒€不是特別熟悉，我這次將main類與Poly類寫到了一起，其實應(yīng)該分離，一個多項式的類，一個項的類，一個main入口類。整體來講結(jié)構(gòu)不是很好，而且有兩個比較長的方法同時分支較多，同時也就造成了它們的獨立路徑數(shù)較多，模塊復(fù)雜度較高。

2. 第二次作業(yè)

2.1 基于類的分析的度量

2.2 基于類間內(nèi)聚和耦合的度量

我的高復(fù)雜度方法體現(xiàn)在輸入處理，輸出處理以及化簡上，這次作業(yè)如何有效的化簡是一個難點。

2.3 UML圖及結(jié)構(gòu)點評

本次作業(yè)的設(shè)計較為體現(xiàn)了面向?qū)ο蟮乃枷?，設(shè)計了一個main入口類，多項式類，項類，因子類，以及其中由于因子是由底數(shù)和指數(shù)組成的，而指數(shù)又有多種形式，故設(shè)計了一個底數(shù)的抽象類base，將常數(shù)類const,冪函數(shù)類power，三角函數(shù)類triangle作為了base的子類，這樣就可以將一個多項式一點點解析成項，因子，底數(shù)，指數(shù)等等。同時，由于每一個類都有共同的特點就是可求導(dǎo)，因此我設(shè)計了一個求導(dǎo)的接口Derivable,所有的類都實現(xiàn)了這個接口，這符合了java面向接口編程的思想，同時也提升了代碼的規(guī)范性。

3. 第三次作業(yè)

3.1 基于類的分析的度量

3.2 基于類間內(nèi)聚和耦合的度量

發(fā)現(xiàn)我的高復(fù)雜度的方法全部都是對于輸入處理上，由此可見我的輸入處理的不太好，寫的十分面向過程且十分容易出錯。

3.3 UML圖及結(jié)構(gòu)點評

本次作業(yè)的架構(gòu)和上一次作業(yè)是完全一致的，因為上次作業(yè)時我就考慮到了程序可擴展性的特點。然而本次作業(yè)在加了表達式因子和嵌套因子后顯得這個架構(gòu)有一些問題。求導(dǎo)部分利用遞歸向下求導(dǎo)的方式倒是不難實現(xiàn)，此次作業(yè)最難的輸入部分我處理的不是很好。這次輸入的難點主要是出現(xiàn)了表達式因子和嵌套，我們?nèi)绾斡谜齽t表達式來正確的識別和解析。我的想法是先找到所有非三角函數(shù)括號中最內(nèi)層的括號，將其解析為一個多項式，這時再解析出該多項式內(nèi)部的三角函數(shù)，把三角函數(shù)括號中嵌套的多項式因子解析到三角函數(shù)的屬性中去，重復(fù)這個步驟直到?jīng)]有括號為止。整個過程雖然可以實現(xiàn)但是十分復(fù)雜，十分面向過程且會有多分支，行數(shù)非常多的方法，復(fù)雜的正則表達式的存在。后來在討論課上聽說的用工廠模式或一個parser的類可以更好的實現(xiàn)該輸入解析過程，parser類里面分別有對poly,item,factor的解析方法，高內(nèi)聚低耦合避免了一大串if-else的出現(xiàn)。

二、Bug分析

1. 第一次作業(yè)

第一次作業(yè)我的強測沒有出現(xiàn)WA的情況，但是被hack了12次(2同質(zhì))，分別是\\s+匹配到\t和空格外的字符的情況、以及直接輸入空格程序crash的情況，程序crash的原因是我在得到字符串之后直接進行了input.trim()操作，導(dǎo)致輸入input變?yōu)榭沾绦騝rash，有兩種更改方式，一種是直接把main方法里面的所有內(nèi)容用try-catch保住，確保程序不會出現(xiàn)crash(這也是我后面兩次作業(yè)的寫法)，另一種方法是在trim()后面再判斷一次串是否為空。對于另外一個bug，我的正則里面寫的是[ \\t]*然而還是出現(xiàn)了bug，這與我程序的設(shè)計結(jié)構(gòu)密切相關(guān)，因為我再剛剛讀入input的時候就用trim()去掉了兩邊的空白符，這樣導(dǎo)致輸入字符串兩邊的\v和\f無法有效的識別WF，造成了bug的出現(xiàn)。我的修改方式是先看所有的輸入字符是否有非法字符，如果有的話直接輸出WF即可。

2. 第二次作業(yè)

第一次作業(yè)我的強測沒有出現(xiàn)WA的情況，但是也被hack了3次(2同質(zhì))，分別是在輸入符號處理中的if表達式中的||手誤寫成了&&，和對于輸入錯誤的匹配沒有識別出WF。仔細想想，這與我的設(shè)計結(jié)構(gòu)也有著千絲萬縷的聯(lián)系。我對于輸入的處理是在去掉了輸入兩邊的空白字符后依據(jù)此時input.CharAt(0)來確定在前面添加"+"或者"+0",然而我沒考慮到*x若在前面"+0"會造成本來是WF的數(shù)據(jù)變成合法，因此導(dǎo)致了bug。另外一個bug就是典型的一大段if-else造成的鍵盤誤操作，這也體現(xiàn)了減少分支數(shù)量降低代碼復(fù)雜度的必要性。

3. 第三次作業(yè)

第三次作業(yè)我的強測WA兩個點，被hack了10次(強互測加起來2同質(zhì))，分別是輸入匹配時正則表達式少了一個[ \\t]*造成的有空格導(dǎo)致不匹配以及一個符號出現(xiàn)了問題。這兩個問題的產(chǎn)生就與我的設(shè)計非常密切的相關(guān)了。我寫了4個正則，其中最大的正則有6行，如此長的正則難免會不小心失誤，寫小正則把問題分開分析是避免這類錯誤的一個很好的方式。而另外一個符號錯誤則完全是由于我的輸入寫得太過復(fù)雜，括號來回匹配的邏輯，比如解析一個item，會返回一個poly.解析一個factor也會返回poly，而每個item都有其固定的符號,這次Bug的出現(xiàn)就是因為在解析item返回poly的時候沒有考慮原來item的符號，而默認"+"造成了錯誤。由此可見，面向?qū)ο蟮脑O(shè)計模式，封裝的好處就是減少耦合，減少出錯點。

三、Hack策略

1. WF

前兩次作業(yè)錯誤主要集中在WF上，這時候就可以手動設(shè)計測試樣例，比如全空格，空串，只輸入常數(shù)，輸入x^0，0*x，si n(x),sin   ( x    )，+++1，++ 1，\f\v，BigInteger,爆棧,......等等，因為前兩次作業(yè)正確性的實現(xiàn)上并不難，主要大家的出錯點在對WF的處理上，因此我的這種策略有效性也很高，前兩次作業(yè)共提交7個測試樣例hack18人次。

2. 正確性問題

第三次作業(yè)強調(diào)正確性的問題，我也從正確性的問題入手，具體方法就是對于指導(dǎo)書上對本次實驗要求的所有功能，先分別構(gòu)造測試數(shù)據(jù)，在將各種模式組合起來，比如sin()里面有表達式，里面還有嵌套的sin()，再加一些項乘起來之類的。覆蓋所有的情況覆蓋所有的功能就能找出bug。由于第三次作業(yè)大家基本都沒怎么優(yōu)化，所以直接看輸出結(jié)果很難看出正誤，因此可以把每位被測者的輸出結(jié)果賦上一個x值(比如x=1.1)比較不同被測者輸出結(jié)果的值是否相等，若不相等顯然是出現(xiàn)了問題。

3. 根據(jù)程序找bug

這種方法難度較大，主要原因是部分代碼可讀性較差，結(jié)構(gòu)不清晰，等等。當(dāng)然如果能看懂對方程序的話肯定是更容易從根源處找到bug。通過白盒測試，對復(fù)雜的類進行單元測試來尋找bug。

四、Applying Creational Pattern

1. 工廠模式

工廠模式(Factory Pattern)是Java中最常用的設(shè)計模式之一,這種類型的設(shè)計模式屬于創(chuàng)建型模式，它提供了一種創(chuàng)建對象的最佳方式。在工廠模式中，我們在創(chuàng)建對象時不會對客戶端暴露創(chuàng)建邏輯，并且是通過使用一個共同的接口來指向新創(chuàng)建的對象。因此，對于本次作業(yè)可以使用工廠模式來創(chuàng)建表達式，項，因子，我們只需定義一個創(chuàng)建對象的接口，讓實現(xiàn)了該接口的子類自己決定實例化哪一個工廠類。在我們明確地計劃不同條件下創(chuàng)建不同實例時，工廠模式將十分管用。

2. 抽象工廠

抽象工廠模式(Abstract Factory Pattern)是圍繞一個超級工廠創(chuàng)建其他工廠。超級工廠又稱為其他工廠的工廠,在抽象工廠模式中，接口是負責(zé)創(chuàng)建一個相關(guān)對象的工廠，不需要顯式指定它們的類。每個生成的工廠都能按照工廠模式提供對象。系統(tǒng)的產(chǎn)品有多于一個的產(chǎn)品族，而系統(tǒng)只消費其中某一族的產(chǎn)品時，可以使用抽象工廠作為所有工廠的抽象父類，這樣我們就不用花費時間在選擇接口上了。

五、總結(jié)與展望

1. 總結(jié)

4周時間過去了，OO也過去了第一單元，早就聽說了OO的恐怖，如今也確實是體驗了一番?？傮w來講第一單元的學(xué)習(xí)還算滿意，測試方面仍需加強，另外就是面向?qū)ο蟮乃枷脒€需不斷的培養(yǎng)。第一單元其實主要還是java的入門，幫助我們更加熟悉java的使用。還有就是感覺今年的OO確實感覺要比往屆好了不少，公測分占主要的情況下大體上保證了課程的公平，分ABC組互測也避免了一些悲慘的情況，總體來講OO課在不斷變好，在此感謝助教和老師的付出！

2. 展望

前路漫漫，道阻且長。后面還有多線程等等很難的知識和作業(yè)在等著我們，希望我們能繼續(xù)努力，在本學(xué)期結(jié)束時能真正有很大的收獲。