oo第一次博客

 1.第一次做業： 在一個java文件中有三個不一樣的類：class inputstring \ class jisuan \

Public class caculate.

Inputstring類主要解決輸入字符串及對字符串進行語法匹配檢查的問題。屬性個數有一個方法個數有四個，分別進行字符串的賦值，字符串的返回，去除空格和語法檢查，其中語法檢查的方法規模較大。前三個方法沒有涉及控制分支，由於都是必然操做。最後的方法有6個控制分支，經過這六個分支排除了不合法的輸入及報告錯誤。

類的總規模在50行左右。

Jisuan 類主要解決對輸入的合法的多項式進行計算的問題。有兩個屬性，分別是字符串和保存結果的數組。有兩個方法分別負責數組的初始化和對多項式計算。第二個方法的規模較大，第一個方法很簡略基本能夠忽略其規模，也沒有分支控制語句由於也是必然操做。第二個方法有3條分支控制語句判斷符號，冪數重複的檢查。

類的總規模在70行左右.

Caculate類調用前兩個類的方法實現最終的完整的多項式計算的功能。規模很小，無分支控制語句。

優缺點評價：最大的優勢是正則表達式的運用，極大地完成處理要求的同時，精簡了代碼，簡化了問題省了大量的時間精力去設計其餘部分。代碼的模塊化實現得好。

缺點是代碼部分地區稍顯繁瑣，存在進一步簡化的可能。

 

Bug分析：因爲運用了正則表達式較好地解決輸入端匹配的問題，因此未發現bug。

發現bug策略：可將全部不合法輸入列舉出來列成表格，而後以交叉聯合的方法進行排列組合使用窮舉的方法完備地發現可能存在的bug。固然在閱讀代碼的配合下可將一些明顯的不會產生bug的輸入選擇剔除表項，進一步地縮小搜索範圍便於更快地定位Bug。

 

 

2.第二次做業：我建了6個public類：Elavator \ Floor \ main \ Request \Requestqueue \Scheduler

Elavator類共有2個屬性，5個方法，分別實現返回時間，樓層，電梯運動狀態，給樓層賦值，計算上下樓層所需時間並更新當前樓層的功能。負責計算的類規模較小，有三個控制分支。

Floor 類有一個屬性，有一個方法，該方法規模很小無控制分支，負責返回樓層。

Request類有4個屬性，6個方法，分別實現返回目標樓層，時間，請求類型 ，電梯運動方向，對這些變量的賦值和計算賦值。其中負責計算的方法有三個控制分支。規模較小。

Requestqueue類中有2個屬性，3個方法，方法規模都很小，只負責返回請求，計數及將新的請求加入到隊列。

Scheduler類中有2個方法，其中一個用於創建隊列處理輸入有14個控制分支，規模較大有100行左右，另外一個用於判斷輸出有2個控制分支，規模較小在20行左右。

Main類規模很小，是調用了Scheduler類中的方法。

類之間的關係：Scheduler類調用了Elavator類，Request類的方法實現輸出。

方法之間的關係：：Scheduler類的scheduler方法分別調用了Elavator類的用來返回計算時間，電梯運動狀態，樓層的三個方法，Request類的用來返回時間，請求，計數的三個方法。

優缺點：優勢是設計的較爲合理，模塊化好。能較好地實現設計要求。

缺點：應使用正則表達式處理輸入，精簡代碼的同時減小錯誤的發生。

Bug分析：輸入的數字爲字母時會發生crash，沒有考慮這種狀況。

 

 3.第三次做業創建了7個類Elavator \ Floor \ main \ Request \RQueue \ Foolscheduler \ ALS_Scheduler \ Moveable：接口

Elavator類未改。

Floor類未改。

Main類調用ALS_Scheduler方法實現完整功能。

Foolscheduler類未改

Request類有6個屬性12個方法。在第二次做業的基礎上加了8個方法用來返回時間，目標樓層，隊列情況，請求類型等信息。還加了tostring方法（未用）。

ALS_Scheduler類有4種屬性2種方法：dispath 和 setqueue 規模較大都在100多行。

Moveable接口有兩個方法，用於時間和電梯情況。

RQueue類有2個屬性，7個方法。

類圖：

 

 

 

 

感想與體會：經過三次做業，我以爲前期有效的設計能夠爲後面的開發減輕很多負擔，要嘗試着去找到符合問題自己的模型並將反映到代碼上。要學着去找到那些有效的工具，好比：正則表達式等等。整體來說代碼具體的實現能力必需要爲上層的架構服務，這樣的設計纔是符合工程須要的。因此在從此更加地要注意前期的設計。