OO第二次總結

第五次做業：多線程電梯

　　以前早就據說此次做業比較難，並且由於某些緣由我開始的比較晚，致使很難按時完成做業，通過權衡，我放棄了此次做業。

 

第六次做業：文件監控

一、設計思路

　　和其餘人的廣泛認知同樣，我也以爲此次做業不是很難。因而，我沒有通過認真思考就開始寫，寫到一半以後，我才發現本身的代碼構造有問題，可是這時候重構以前的代碼又要花費大量時間，因而我乾脆沒有改前面的代碼。結果，當我寫完此次做業以後，我發現本身的代碼寫得很是醜，由於代碼中的冗餘部分佔了至少三分之一。

　　個人設計思路仍是很符合指導書的，主要就是構造和比對監控範圍的切片，根據要求輸出變化。我還按照指導書編寫了線程安全的文件類SafeFile，一開始，我給這個類定義了一個File類屬性，而後定義了一些帶有synchronize關鍵字的方法來實現文件操做。可是後來在構建代碼的過程當中我愈來愈以爲這個File類的屬性沒有太大用處，因而我去掉了這個屬性。後來通過同窗的介紹，我發現徹底能夠把SafeFile類中的方法所有寫成靜態方法，這樣的話既省去了實例化對象的步驟又最高程度地保證了線程安全，可謂一箭雙鵰。

二、度量化分析

　　僅從上圖的Total Lines of Code一項就能夠看出個人代碼寫得有多醜，由於我用了別人兩倍的代碼行數。究其緣由，實際上是我把監控文件和監控文件夾兩個功能分開了，而後又把renamed等四個功能又分開了，這就致使個人代碼有八個包含大量重複代碼的獨立的類，其實他們徹底能夠合併成一個或兩個類。

三、類圖

 

四、bug分析

　　本次做業不管是公測仍是互測我都沒有被發現bug，能夠說是很幸運了。其實這也在乎料之中，由於我在本身測試的時候就很難發現bug，並且個人SafeFile類寫得很是線程安全。

　　我分配到的那個測試代碼沒有線程安全類的bug，但有一個結構上的錯誤，例如當我監控test文件夾下的a.txt文件的renamed時，若是test文件夾下的一個子文件夾內已經包含一個與a.txt徹底相同（能夠理解爲複製過去）的文件，那麼他的程序會把這兩個徹底相同的a.txt識別爲一個path-changed變化並輸出（也就是說無視了輸入的renamed監控，這讓我感到很是奇怪）。估計是因爲相同的問題，他的公測有四個點過不了。我翻看了他的代碼，發現他寫得比較簡潔，至少比我寫得簡潔多了，可是出現這樣嚴重的錯誤實在很惋惜。

 

第七次做業：出租車1

一、設計思路

　　雖然我沒有寫第五次做業，但我仍是構思了的，我以爲這兩次做業的思路很是類似。Map類負責打開並讀入並存儲地圖。InputHandler負責把控制檯的輸入轉化成請求並把有效的請求輸入到線程安全的請求隊列中，SchedulerMaster負責過濾同質請求而且爲每一個請求建立Scheduler線程，Scheduler會建立WindowTime線程，3秒內記錄搶單的出租車信息，3秒後，根據一系列標準選出派單的出租車，把訂單信息告知Taxi類，而後Driver線程檢測到Taxi類的屬性變化，開始控制Taxi接乘客、送乘客。用上次做業編寫的SafeFile類中的write方法完成寫文件操做。

 

二、度量化分析

 

　　很遺憾，從上圖能夠看出我此次做業又寫了一千多行，能夠說又寫得比較「冗餘」了，其餘部分好像也比較有問題，不是很面向對象，儘管我已經比較努力地在寫了。

三、類圖

 

四、bug分析

　　此次做業我又沒有被找出bug，能夠說是很是幸運了，可是文檔等級是通常，所以在之後的做業中仍是要更認真地寫。其實個人代碼有一個問題，不知道爲何，個人代碼在運行的時候，時不時會致使gui類報錯：地圖不是連通的！而後退出程序。這讓我感到迷惑不解，由於講道理我寫的代碼不會影響gui的算法，可是他的算法竟然能讓邊界點到某一點的距離爲MAX，而後報地圖不是連通的錯，實在是讓人匪夷所思。後來我把他的報錯和結束程序部分的代碼註釋掉，這下就能夠完美運行了。總的來講能夠說是很迷了。

　　此次我分配到的那個代碼又是十分的乾淨整潔，文檔也寫得很不錯，只是一百輛出租車輸出到一百個文檔裏讓我測起來很吃力。我用了不少方法都測不出bug，能夠說這是一份很是優秀的做業了。

 

心得體會

　　經過這兩次做業，我對線程安全的編程方法有了必定的瞭解，也在同窗的幫助之下學會了使用靜態方法來解決線程安全問題。設計原則方面我愈來愈注重面向對象，像前三次做業那樣幾百行的方法幾乎已經沒有了，開始變得「比較高內聚，比較低耦合」。最後但願第七次做業是後面一系列出租車做業的一個良好的開始，也但願我從此經過學習能對面向對象編程有更深刻的理解。