面向對象第三單元訓練總結

1、規格化設計概述

規格化設計主要爲程序設計提供分解、精化和抽象的手段。在撰寫代碼規格的過程當中，須要對其組成部件進行抽象。 不然, 若是每個組成部件都以本身特有的行爲方式運轉, 不一樣的組成部件交織在一塊兒, 那麼規格的撰寫可能同軟件實現同樣複雜。

過程抽象和數據抽象是兩種有用的抽象方法。過程抽象把一組輸入映射到一組輸出上, 包含了數據抽象, 並經過數據抽象的行爲來定義。數據抽象提供了一組數據以及施加在這組數據上的操做。儘管這些操做也可視爲一種過程抽象, 可是把數據抽象看成一個總體更能體現出它和現實世界實體的對應關係。

在軟件生命週期的開始階段採用規格化設計每每要等到之後的階段中才能顯示出它的促進做用。例如, 規格說明劃分了軟件模塊使用者和實現者的責任, 避免了編碼階段可能出現的混亂。因此, 撰寫規格時既要考慮到特定開發階段的特色, 又要聯繫整個軟件生命週期, 統籌規劃。

規格化設計是一個天然而然的過程。當人們發現僅靠語言和文檔的溝通已經沒法知足大規模代碼的合做開發須要的時候，規格便應運而生。規格化設計有利於作到設計與實現分離，雖然前期撰寫規格花費了必定的時間，但換來了後續代碼實現的順暢，所以獲得了人們的重視。

2、做業中的規格Bug

做業次數	Bug樹分支名稱	所在類/方法	所在行數
9	無	無	無
10	Overview是否明確抽象對象	class Taxi	17
11	Requires不完整	Map.open	242
11	Effects內容爲實現算法	Taxi.goTakingOrder	293

3、規格Bug產生的緣由

第10次做業中的Overview未明確抽象對象，是由於本身當時對Overview做用的理解並不深入。後來我參考了一下操做系統實驗課的各類函數的Overview，大體明白了Overview在規格化設計中所起到的做用：爲該類的使用者營造一個不須要仔細閱讀代碼就可以理解該類用途和大體使用方式的環境，明確類的職責和其管理並負責的數據；以後，按照Overview去實現類的各類屬性和方法，確保該類不會越過本身的職責範圍。

第11次做業的Requires不完整是我沒有完整考慮到方法裏對方法參數的全部要求。在該方法中，我利用傳入的兩個參數去訪問一個數組，若是傳入的參數不合適，就會發生數組越界異常。這說明個人REQUIRES限制範圍太寬，應加以限制，或在代碼中對上述的特殊狀況加以處理。

第11次做業的Effects內容爲實現算法是由於個人某些方法作的事情太多，更改了許多屬性，又調用了許多其餘方法，還夾雜了睡眠，致使該方法的耦合度極高，牽一髮而動全身，沒法用簡短的話語歸納方法的行爲。對此我認爲，應該將這種過於複雜的方法加以肢解，使其成爲一個個小的方法，這樣能夠有效減小代碼之間的耦合度。

4、前置規格和後置規格的現狀與改進

一、前置規格（改進後的前置規格以REQUIRES_NEW在圖中標明）

二、後置規格（改進後的後置規格以EFFECTS_NEW在圖中標明）

5、功能Bug與規格Bug在方法上的彙集關係

做業次數	Bug樹分支名稱	所在類/方法	功能Bug
9	無	無	無
10	Overview是否明確抽象對象	class Taxi	無
11	Requires不完整	Map.open	無
11	Effects內容爲實現算法	Taxi.goTakingOrder	無

由上表可見，功能Bug和規格Bug的彙集關係並不大。一個可能的緣由是，功能Bug的測試較爲困難，但許多規格Bug是顯而易見的，所以測試者偏向於更多地去報規格Bug，而只能在邊角處挑一些功能Bug；這些邊角功能所在的方法都比較簡短，一般不存在規格Bug。這也是我認爲目前課程體系互測制度中須要改進的地方：規格Bug的扣分限制過少（或者說性價比過高）且基本沒法申訴，使測試者們傾向於扣規格分，而忽視程序在主要功能上的Bug。這可能會致使一些致命的程序設計問題被掩蓋，也必定程度上下降了課程的訓練效果（不管是對被測者而言仍是測試者而言）。

6、思路與體會

使用規格化設計的最佳時機是程序已經有了大體思路、但還沒開始落實到代碼的時候。經過提早設計好各個類和類中各個方法的規格，咱們能夠在無需實現的狀況下，對整個系統作出一個良好的設計，從而下降後續開發的難度。在這個階段，規格化設計還能夠更好地幫助咱們發現本身思路上的問題——例如，若是某一個方法的JSF寫不下去了或不知道該如何下手，多半就是沒考慮好該方法在整個系統裏所起到的做用。從這個角度上來說，撰寫規格雖然花費了必定的精力，但其帶來的價值卻遠超撰寫規格的時間開銷。

即便是先實現了代碼、再補充規格，爲方法撰寫規格依然可以使咱們從新審視本身的設計。若是某一個方法過於龐雜，撰寫規格時難如下手，那麼這個方法多半耦合性太強，可能須要重構。過後撰寫規格，其實是倒逼咱們回顧整個系統，從好的方法（便可以清晰地用規格描述的方法）中獲得經驗，從壞的方法（即難以撰寫規格的方法）中獲得教訓，這對於咱們從此的軟件開發生涯有很大的幫助。

然而，目前課程的制度安排上仍然存在一些不足，例如，規格要求太過死板（後置條件是否必定要用布爾表達式？有些時候，天然語言比布爾表達式更能表達出方法的執行效果，也更容易理解，畢竟規格寫出來是給人看的），扣分制度有待改善（測試者在報告規格Bug的時候沒有約束，可能致使惡意扣分）、各類Bug的權重尚需調整（邊角Bug和主要功能上的Bug是否應該具備相同的權重？地圖文件沒有過濾製表符，和一輛出租車接了兩個單，是否應該扣除相同的分數？筆誤帶來的規格錯誤和壓根牛頭不對馬嘴的規格錯誤，這兩類問題是否應該採用同一種扣分標準？），這些都是在歷次互測中體現出來的問題，也是課程體系中實際存在了許多年、但仍然沒有作出有效改進的地方。

做爲一名北航計算機學院的學生，我固然是但願面向對象這門課程愈來愈好，讓更多的人不是去吐槽它，而是真正感覺到面向對象帶來的好處。但願課程組在以後的幾回做業中，可以對互測規則作出一些針對性的改進，不要讓同窗們編程的熱情被永無止境的規格扣分上的爭辯所消磨殆盡。