面向對象5-7次做業總結

1、第五次做業——多線程電梯

1.設計考慮

　　此次主要的數據共享產生在調度器和輸入線程共享了輸入的請求隊列，以及在每一個電梯線程和調度器線程各自共享電梯的狀態。所以在設計的時候主要要對這兩處數據共享進行同步保護。如今看來當時本身設計仍是有必定問題的，作到了將輸入線程和調度器線程之間的共享對象抽取出來一個隊列類，可是在處理調度器線程和電梯線程的時候採用了將電梯的狀態存入到電梯線程的作法，這種設計給維護電梯狀態的同步帶來了比較大的挑戰。

　　除了多線程的同步設計以外，本次做業最大額矛盾點就在於如何在多線程調度花費時間的實際狀況下知足指導書要求保證輸出的時間不能產生偏差。雖然指導書給了100ms的時間偏差，可是這個時間間隔對於指令條數比較多的狀況下在CPU性能比較差的電腦上就不夠了。所以此次爲了不這個偏差問題，每次爬樓梯的線程休眠的時間不是固定3000ms不變，而是動態變化的（根據此次調度花費了多少時間相應的就少睡多久，這樣基本保證了每次都在不停地消除偏差）。

2.OO度量

(1)OO度量

 　　看到主要問題仍是出如今方法嵌套層數有點多，之後再寫代碼的時候會多注意這個問題的，儘可能減小嵌套層數。

(2)類圖分析

 基本設計思路是：Main線程啓動輸入線程，調度器線程以及電梯線程，而後每次從輸入線程讀入的請求會加入到請求隊列中，調度器線程會掃描請求隊列，而後爲其分配電梯，給相應電梯設置上下行相關的狀態以及目標樓層，而後電梯本身運動。

(3)時序圖

 

　　設計原則自我反思：此次做業將大量的精力放到了處理共享數據的同步問題，加上此時課堂上尚未對設計原則進行系統地講解，因此設計的代碼風格不太理想。好比Lift類就違背了類的單一職責原則（將線程和共享數據放在一個類裏面加大了同步控制的難度），還有如今看來違背了顯式表達原則，代碼中大量使用常量（應該使用enum類型）。

3.bug分析

(1)自我bug分析

　　此次做業公測和互測階段都沒有被找出bug，可是在交做業的前一天仍是發現了一些本身的問題，而且對這些問題進行了修改。在此之中最致命的一個就是代碼有如下兩個邏輯語句：一個是將調度器判斷完若是指令能夠被電梯執行的時候就會設置電梯的狀態成爲上下行以及同層開門，另外一個是設置已經發生空閒等待的電梯的電梯內時間成爲請求發出的時間。我最初在設置的時候是按照上面所說的順序進行執行操做的可是致使最後先設置完狀態後直接跳轉到電梯線程，致使sleep的時間出現負數報錯。最後仍是將這兩個操做使用鎖鎖起來才順利解決這個問題。這個仍是對應設計的時候沒有徹底考慮到線程之間的同步問題，其實關於同步和互斥這兩個多線程最重要的問題我直到一週前的操做系統課上老師講我才真正理解兩者之間的區別與聯繫。

(2)互測bug分析

　　仍是遵照了之前的測試習慣，先將本身在編寫代碼中留下來的測試數據對對方程序進行測試，發現問題比較明顯，因而去定位相關的代碼，發現對面的代碼在計算輸出時間的時候出現了一些問題，並相應針對幾個漏洞點進行了相關樣例構造以及測試。

 

2、第六次做業——IFTTT

1.設計考慮

　　此次做業是第二次進行多線程編程的做業，有了上一次的鋪墊，此次對多線程的設計方法有了更深刻的理解，對同步控制的運用更加熟練了，於是此次做業的本身也在有意識的向良好的設計原則上靠攏。在設計環節上將每種觸發器的3種觸發器整合到一個類裏面。最開始本身的設計是隻有一個觸發器對象，裏面是許許多多的if-else分支判斷不一樣的觸發器類別以及相應的觸發動做，致使代碼的可讀性極差、這個觸發器類的複雜度十分高。後來審視了一下本身的設計，發現四種不一樣的觸發器之間有共性的特徵，同時也存在不小的差別，所以真正第一次本身設計使用了繼承機制（第2、三次做業雖然也有要求，可是都是名義上的假繼承，沒有任何複用代碼和數據），構建了觸發器父類以及對應重命名觸發器、大小改變觸發器，路徑改變觸發器、最後修改時間觸發器這4個類，並真正運用了接口讓對應的觸發器進行實現。

　　此次共享對象的同步控制仍是比較明顯的，在指導書裏面基本上已經給出了比較明確的指引方向，主要點就是SafeFile類，我採用了將整個MyFile類的每個方法聲明成靜態類，在summary和detail調用寫文件的時候必須拿到這個類的鎖才能正常寫入，這樣同步控制是很是簡單的，可是同時也犧牲了必定的效率，還有較大的改進空間。

2.OO度量

 （1）OO度量圖

(2)類圖

 此次的主要設計思路是：輸入線程和主線程先啓動，輸入線程構造出監視任務（Task類），而後分別啓動對應的相關監視線程（分別是4個子類，他們都繼承同一個父類），在觸發器監視線程中，每一個100ms對文件進行一次掃描，並記錄下一次快照(FileSnapShot類)，而後對比分析，若是須要輸出相關內容到文件則使用Detail和Summary類進行輸出。

(3)時序圖

 

 

 

　　設計原則反思：此次做業對於設計原則的思考有了很大的進步，第一次本身在真正實踐編程過程當中意識到了繼承和接口機制的真實做用。將幾個觸發器的通性抽象成一個父類，可是這次仍是使用了過多的常量表示狀態，仍是違背了顯式表達原則。

3.bug分析

(1)本身程序分析

　　本次做業在設計的時候在判斷監控對象數目的時候出現了紕漏。出現的問題類定位在了Input類，反思總結最主要的緣由是設計的可拓展性不強，致使發現助教對指導書有了新的解釋以後本身添加新要求的時候形成代碼改動較大，導致出錯。最開始本身對於監控對象理解成了一行輸入算一個監控對象，可是後來助教解釋說是一個文件或者目錄算一個監控對象，在改正代碼的過程當中判斷出現了問題。在修改後測試測試到了輸入11個文件發現能夠正常報錯可是忽略了若是輸入十個文件可是某個文件有多個監控的狀況，致使輸入超過10個會被程序誤判成超過監控對象數量範圍。這個問題暴露的仍是設置的時候只顧眼前沒有考慮到後期可能產生的修改以及在作完修改後從新測試時沒有作到完備測試。

(2)互測bug分析

        本次測試的對方代碼很簡潔、邏輯條理很清晰，沒有找到什麼bug，可是仍是從對面的同窗的設計思路上獲益匪淺。

3、第七次做業——出租車

1.設計考慮

        本次做業的設計思路和多線程電梯的設計思路基本上保持了一致。在老師講了許多設計原則以後，也針對第五次做業之中許多不合理的設計細節進行了修改。大致思路仍是調度器和輸入線程共享乘客請求隊列，調度器和出租車線程之間共享出租車的狀態變量線程。本次設計拋棄了上次的將出租車的狀態和出租車線程結合的設計（上次這樣設計致使最後同步控制邏輯異常複雜），此次採用了將線程和共享變量互相分離的方法，使得出租車線程裏面不須要進行任何的同步控制。

        除此以外在設計的時候由於有了更加細緻的設計要求指南，因此此次在設計的時候儘量讓本身遵照着課上提到的設計原則。好比爲了遵照顯示錶達原則，將之前定義常量數字來表示狀態的作法改爲了使用enum枚舉類型表示相應的狀態。同時查閱並接觸了有關面向接口編程的基本思想，開始逐步嘗試真正作到使用接口來讓本身的程序更加簡潔堅固（雖然第二次做業也有要求使用接口，可是那時候的本身真的是爲了編接口而編接口）。

2.OO度量以及程序分析

(1)OO度量

 　　看到主要問題仍是出如今方法嵌套層數有點多，之後再寫代碼的時候會多注意這個問題的，儘可能減小嵌套層數。

(2)類圖分析

 類圖介紹：

將系統分爲如下幾種處理方面：a.輸入類：按照設計從控制檯輸入乘客乘車請求或者查詢出租車請求，構建輸入類InputDeal主要用於輸入處理以及將乘客乘車請求添加到請求隊列之中。

b.乘客請求類：將乘客抽象成一個請求類Request並構建線程安全類RequestQueue進行請求存儲以及刪除

c.調度線程類：Scheduler模擬真實的控制中心，作到模擬窗口期以及相應的派單工做，第二個是RequestMap類對應指導書的在請求進入以後進行廣播操做（標記某點有請求，讓出租車搶單）

d.出租車以及線程類：將出租車的共享變量封裝在Taxi類裏，並用TaxiThread模擬出租車線程進行運行

e．map類用於初始化地圖並在程序開始將全部最短路徑進行計算存檔

f.測試接口類：提供測試須要的接口

g.輔助類：OutputTestInfo用於輸出測試時輸入的查詢出租車結果，Time類封裝了得到時間的方法，發現系統System.CurrentMills()得到時間的速度太慢，查閱資料將System.nanoTime()以及獲得對應的模100向上取整的方法封裝到了Time類。

 

(3)時序圖

 

 

 

 

　　設計原則自我檢查：因爲有了一個設計原則指南，在設計的時候就要求本身儘量按照標準規則來設計，此次凡是用於表達狀態的都運用了enum枚舉類型代替，也將類的職責拆開，儘可能作到各司其職，自我感受比前兩次做業的設計有了進步。

3.bug分析

(1)自我bug分析

　　此次做業被抓到一個bug，緣由仍是跟指導書理解有偏頗，又沒有及時看到issue裏所說的。我理解的輸出搶單信息是輸出搶單時刻對應車的信息（爲了判斷是否搶單的時候車輛處於請求的輻射範圍），可是issue裏最後說了輸出的搶單信息是窗口期結束的時候各個在窗口期進行過搶單的車輛的信息（主要是判斷最後分配時刻是否符合派單的要求）。這提醒本身要定時刷issue。

(2)互測bug分析

        本次做業公測主要的測試內容都是對於格式的測試，也從側面說明了此次測試的難度之大，因此拿到代碼常規測試了幾個本身在編寫代碼過程當中簡單的樣例後就開始在讀代碼的過程當中對設計原則進行檢查和針對代碼進行測試。在讀到輸入處理的時候檢查到對面輸入處理的時候有正則處理失誤，併發如今選擇出租車接單的時候存在調度上的錯誤，針對這兩個讀到的問問題構造了bug並上報。在測試過程當中並無發現對面在線程安全方面產生了問題。

 

5、心得體會

1.線程安全設計：第三次電梯做業是這學期接觸的第一次多線程做業，第一次多線程做業是最艱苦的，整整花了一個清明節假期先後很長時間才順利完成。當時採用的設計以及線程安全控制措施也是很是不成熟的。第一次多線程電梯將電梯線程以及電梯的狀態變量相關的共享數據寫到了一個類裏面，致使類的規模十分龐大，維護線程同步的成本也是比較大。在出租車的時候已經充分意識到了將線程和共享變量類抽離的必要性，並將這種思想落實到了代碼之中。

2.本單元的做業本身也開始有意識地在設計的時候遵循設計原則，第五次電梯因爲第一次接觸多線程，於是大部分精力都投入到了同步控制上，設計上就比較幼稚。第六次做業的時候本身第一次真正體會到繼承以及接口在設計時的必要性，第七次做業有了更加詳細的設計原則指導，在設計的時候就更加規範。