OO第三次總結

規格化設計的發展歷史

        1950年代，第一次分離，主程序與子程序的分離結構是樹狀模型，子程序可先於主程序編寫。經過使用庫函數來簡化編程，實現最初的代碼重用。產生基本的軟件開發過程：分析—設計—編碼—測試，使大型軟件系統的開發成爲可能。

       1975—1980年代，第二次分離，規格說明（Spec）和體（body）的分離說明是類型定義和操做描述，體是操做的具體實現。（具體的例子就是C++,Java等面嚮對象語言的類說明與類實現的分離。）解決方案設計只關注說明，實現時引用或者設計體。體的更改、置換不影響規格說明，保證了可移植性。支持多機系統，但要一樣環境。此時產生了劃時代的面向對象技術。

       1995—2000年代，第三次分離，對象使用和對象實現的分離基於構件開發：標準化的軟件構件如同硬件IC，可插拔，使用者只用外特性，不計內部實現。Web Services：軟件就是服務。分佈式，跨平臺，鬆耦合。

 

規格化設計爲什麼獲得你們的重視

　　一方面，規格化設計能夠幫助開發者理清思路，構建一個寫程序的框架，這樣一來開發者能夠按照既定的套路來完成本身的任務，從而可以摒棄雜念，提升效率。

　   另外一方面，一個程序中不少代碼會以一塊一塊的形式被反覆使用，這些重複的代碼塊有可能被封裝爲函數反覆使用，也有可能被放入庫中供他人使用。若是能按照必定的規格去完成他們，那麼調用者沒必要大費周折的去理解代碼，能夠經過已有的對於格式的學習以及清晰明瞭的格式來快速完成對代碼的理解，從而提升學習工做的效率。

 

被報告的規格bug

　　很幸運的是，個人JSF沒有被人報BUG，雖然個人JSF寫的很差，並無用布爾表達式把他們實現，而且大量使用了漢語。再具體分析，個人JSF對於因果邏輯上的判斷不夠嚴謹，天然語言有些粗糙且不能充分展現細節，這些都是本身程序裏的缺陷。

 

JSF很差的寫法

　　如上一條所言，個人JSF大量使用了天然語言，這是最很差的地方。假若我使用了純粹的布爾表達式，也可能會犯過於簡略的毛病。可是有的類又寫的很長，若是徹底按照要求來寫，那麼會使得JSF特別長從而難以理解。因此最好的辦法是在設計的時候就作好規格化的設計，使得程序的每一個模塊都大小適中，這樣組織起來才能井井有理。對於問題的處理也務必要清晰，不能夠模糊，不可馬虎大意。

 

功能BUG

　　這幾回出租車做業的BUG相對來講不算太多，第九次的問題有出租車能夠接單可是沒有接單的狀況，緣由是請求的線程沒有及時將請求加入請求隊列中，在進行了相應的阻塞後得以解決。第十次的問題是LoadFile加載出租車多量的時候出現了問題，緣由是在出租車隊列初始化以前就進行LoadFile改變了出租車的狀態，可是在初始化以後出租車的狀態又變回去了，再調整了代碼順序後問題獲得解決。第十一次做業沒有被檢查，本身不太強的測試沒有找到BUG。