OO第一次博客

代碼分析

以第三次OO做業的代碼爲分析對象。

度量分析

類圖

灰線爲包內關聯，紅線爲跨包關聯。 詳細類圖。

自我評價

一些花了心思的設計

• Registry類的設計是源於我注意到我有遍歷全部實現了Busyable, Commandar接口的對象的需求。故而利用工廠方法，使得全部實現了某個接口的對象在完成對象構造後會將本身註冊進對應的Registry中。以後只須要訪問對應的Registry就能夠遍歷全部實現了該接口的對象。
• AlterCenter類的設計是由於我注意到電梯自身對於指令也是有處理優先級的，這一部分邏輯沒必要放在Command類中進行處理。剝離出這部分邏輯可使得Lift類在多指令源的環境下依然健壯執行，也簡化了調度邏輯。
• Commandar接口與Busyable接口的設計，與Registry類的結合，將本來不得不在編碼在調度中的邏輯分散到了各個Commandar,Busyable實現類中，極大地簡化了指令獲取的邏輯與程序運行結束的邏輯。

自我反省

• Command類同時承擔了對輸入的解析與電梯運行邏輯的執行，顯得過於臃腫。或許引入一個Inputer來剝離對輸入的解析，使得Command類變成與IO無關的類是個更好的作法。
• Outputer僅僅做爲一個字符串處理的方法集合存在，實際的輸出零散在各個類中，當須要更改輸出方式的時候，我就把本身逼到死路了。或許使Outputer更充實一點，將輸出邏輯更進一步地封裝在Outputer中是個更好的作法。
• 全部的異常都是以RuntimeException形式存在，在異常處理的時候沒法從異常對象中更進一步地獲取信息，也沒法在捕獲異常的時候根據異常類型區分處理。或許派生出屬於本身的異常時個更好的作法。
• 過於單薄的Building類，由於本來並不存在這個類，但我注意到CommandQuery, Floor, Lift之間須要一層更高級的類來綁定它們，使得它們能抱成團。可是在以後的版本更迭中我忽視了Building類的存在，並無將CommandQuery, Floor, Lift類的交互邏輯抽象進Building類中。
• Timable類的設計顯得局部。本意是由於須要模擬時間，因此引入一個「該對象會隨時間自動發生變化」的抽象接口，可是並無爲其準備充分的資源。像是若是時間流逝的時候兩個對象須要發生相互做用之類的狀況並無考慮進去，而僅僅只是用來進行Lift類的狀態更新與World類的時間流逝。

---

分析本身被找到的bug

但我公測和互測都沒被找到bug……

---

代碼測試策略

1.利用測試樣例覆蓋bug

利用編寫的樣例集，試圖覆蓋到程序的bug。

大多數時候是有效的也是惟一的手段，哪怕經過其餘手段發現了可能的bug，最終也是用測試樣例來確實地認定bug。

可是測試樣例不可能覆蓋到所有可能，一些出現條件苛刻而複雜的狀況難以被覆蓋到。

故而利用測試樣例覆蓋bug只能做爲剛拿到程序時的摸索手段，或利用其它手段測試完程序後對bug的驗證手段。

2.檢查代碼邏輯部分

檢查代碼的if,while等邏輯部分的處理是否正常。

大多數的bug都是出現於代碼邏輯部分，故而優先檢查if的判斷語句、while的判斷語句等邏輯語句是否正常，每每比較容易定位到代碼的bug所在。

可是代碼中的邏輯部分過於龐大、複雜，邏輯互相嵌套致使複雜度爆炸的狀況也廣泛存在，致使更多時候並不能徹底肯定邏輯部分代碼的正確與否。

故而檢查代碼的邏輯部分這一手段僅適合用於局部邏輯的檢查，不適合大規模代碼的測試。

3.繪製控制流圖

將代碼中有大量判斷分支的邏輯塊繪製成控制流圖，經過檢查流圖是否有缺支來尋找bug。

複雜的判斷嵌套容易致使邏輯上的遺漏，經過繪製控制流圖，有條理地分析每個節點應有的邏輯分支，有助於發現被遺漏的分支。

沒法處理過於複雜的邏輯，當由於遞歸、嵌套循環等而致使複雜度爆炸時，難以簡單地利用流圖表示。

故而控制流圖僅適用於字符串處理等線性邏輯的代碼分析。

---

心得體會

第一次維護須要給別人看的代碼（笑），之前就算是要維護代碼，也只是維護一些本身用的小程序，因此不少地方都是「這麼搞也不要緊，反正之後我也不會加那種功能」。可是此次面臨的是未知的下次做業，以及隨時可能更新的需求說明，因此每次OO做業都須要在完成本次做業的前提下儘可能留下下次做業的餘地，以免逐漸把本身逼到走投無路、最後胡亂重構一氣的下場。

一點對類設計的想法

我所遵循的設計流程是（通常都是邊散步邊在手機上作的x）：

1. 研讀需求
2. 構造平凡樣例，檢驗對需求理解的正確性
3. 構造非平凡樣例，再次檢驗
4. 從需求中抽象出主要的幾個類
5. 劃定主要類的邏輯分工，同時抽象出BC,Interface等邏輯基類
6. 安排主要類的主要屬性的結構、對外的主要接口
7. 腦內模擬跑樣例，檢查主要類設計的正確性
8. 設計輔助類，充實主要類的屬性、接口，同時反省類設計的可行性
9. 腦內模擬跑樣例，檢查類設計的正確性

一些可能與他人不太同樣的設計想法：

1. 在開始編寫以前，我會盡可能在時間容許的條件下寫一些樣例來對設計進行測試，以確保設計的正確性。編寫測試樣例的過程自己也有助於對需求的解讀。
2. 類的層次結構在主要類被抽象出來的時候就被肯定了。我儘可能避免在設計過程當中變動類的層次結構，它牽涉到設計的方方面面，我會盡可能最早肯定下來它。
3. 可行性的斷定我會在編寫前就嘗試進行。大多數宏觀的想法能夠在設計過程當中就驗證是否可行，不必放到編寫時再進行。

一點對測試的想法

1. 能夠邊讀代碼邊寫測試樣例。代碼中的許多邏輯分支其實就和輸入分支樹的分支一一對應。
2. 自動化測試手段至關重要。由於咱們的做業時間極其有限（通常來講週末寫完，也就週一到週三的晚上時間能夠debug，還不算文檔撰寫、其餘課的做業的時間），重複勞動浪費的時間在總工做時間中佔的比例至關可觀。寫一些自動化的測試腳本啥的能夠說是一勞永逸。