oo做業總結報告

oo第一次博客　

　　之前從未真正的寫過Java代碼，接觸Java也只是寒假的時候簡單的看了看語法，不懂該如何面向對象，但沒事，內心不懼，想着什麼都是能夠學的（直到真正開始寫工程的時候，才發現本身仍是太天真了），就這樣開始了OO學習這條不歸路。

1、三次做業的實現過程分析　　

第一次做業

　　第一次做業是多項式加減運算，首先我用c語言寫了一遍，基本熟悉題目的具體要求，當用Java去寫時，我遇到了下面一系列的問題（具備難度等級）：

       　1. 該如何劃分類，如何面向對象編程；

       　2.正則表達式是什麼；

       　3.該如何用Java來實現（語法知識）；

      什麼都不懂，那就只好去找資源了，花了一成天的時間去看教學視頻、Java教程、上網搜索博客，快速瞭解Java的基本語法，還有正則表達式的基本用法，但面向對象是個什麼仍是感受很迷糊。這個時候最有效的辦法固然是和大佬進行交流交流了，在我舍友的幫助下，我腦殼裏逐漸有了清晰的設計模式，可是不是面向對象就是另一回事了，最後事實證實，就是面向過程。

　　類圖

　　

　　度量

　　

 

第二次做業

　　第二次做業相對第一次較好一些了，但對於使用面向對象編程仍是不太靈活，感受本身的類劃分不太合理，很不均衡，但又迫於時間的壓力，最後不得不動手寫代碼；

　　面臨的問題：

　　1.類的劃分與交互問題（花費時間最長的工做了）；

　　2.指導書的真正含義，感受很難懂了；

　　3.調度算法問題（選擇什麼算法）；

　　根據要求主要分了電梯類，樓層類，請求類，請求隊列類，調度類。

　　類圖

　　

 

　　度量

　　

 

第三次做業

　　第三次做業也是一個挑戰（其實每一次OO做業對於我來講都是很大的挑戰了，笑哭），從傻瓜電梯到A Little Smart 電梯，增長了可稍帶功能，可我卻不是僅僅就添加了可稍帶功能，我將第二次的代碼所有重構了，心血歷程了。

　　當我從新看我傻瓜電梯的代碼時，我意識到其實本身仍是在面向過程編程，對於類的職責的劃分很是不均勻，致使某些類規模較大，而有些類卻寥寥幾行，而且發現本身當初對於每一個類的功能和屬性的認識還不夠到位，爲了後續代碼的可擴展性，因而毅然決然的重構了全部的代碼，將各個類的屬性和功能都作了較大的調整。

　　類圖

　　

 

　　度量

　　

　

相對於第二次做業第三次做業作的改變：

　　1.電梯類繼承於接口，有了up和down方法，而且有對於電梯內請求的處理，使得各個方法間者職責劃分更加清晰；

　　2.樓層類添加了對於樓層請求的處理；

　　3..根據實際狀況，請求都是從電梯類和樓層類中發出的，因而我就模擬了這種行爲，將從控制面板中讀到的請求交給樓層和電梯，而後再由樓層和電梯交給請求類，進行處理分析，最後再交由請求隊列類，進行處理；

　　4.將程序入口從調度器中分離出來；

　　5.調度器中寫了兩個主要的方法，判斷同質和判斷捎帶，避免了第二次做業中所有都在主函數中處理的狀況，儘可能將功能進行封裝；

 

如今看來第三次做業的缺點：

　　1. 主函數仍是顯得冗長，而且調度器承擔了較大的職責；

　　2.以爲判斷同質不該該放在調度器中，能夠放在請求類中，這樣凡是進入請求隊列中的請求都是可執行的請求，請求隊列也就不會由於同質而再進行改變，提升其獨立性；

　　3.代碼風格不太嚴謹，會顯得比較醜，有閱讀障礙；

 

對三次做業度量結果的分析

　　三次度量結果是具備共性的，因此這裏放在一塊兒說明了。能夠看出main和調度類圈複雜度比較高，主要緣由在於其中的if，while邏輯較爲複雜，可是對於輸入的判斷條件確實不少呀，也不知道怎樣再減小了。其實這裏有個問題搞不明白，對於多個&&條件，是寫在一個if中好，仍是寫多個if_else if 好，在效率方面有區別嗎，仍是說只是代碼風格觀看上的區別？

 

2、  BUG分析

第一次做業　　

　　因爲輸出錯誤信息的內容與標準輸出不一致，掛了十幾個點，怕是沒有像我這麼菜的人了吧；

　　數據過大而致使的crash，當時並不知道還有try_catch這種操做，強烈建議寫try_catch；

　　在設計的時候沒有考慮到數據過大的問題，底下測試的數據也都較小，故出現了此種錯誤；

第二次做業

      第二次做業互測和公測都沒有bug,也許是吃一塹，長一智吧，主要緣由仍是課下的測試樣例比較充分，但也許還存在什麼未知的錯誤，不過是如今還沒找出來罷了。

第三次做業

　　公測掛了十一個點，其中十個點是由於輸出的錯誤信息和標準輸出不匹配致使的，我也是萬般心痛了，本身辛辛苦苦熬夜的成果，卻被這樣的低級錯誤所有毀掉，也許痛了纔會長記性，只能安慰本身幸虧這樣的錯誤在這個時候及時的出現，而不是在之後工做時出現的。互測沒有被測出bug,但其實當天我就發現了本身代碼的另外兩個bug，公測也沒有測出來(其實感受第三次公測挺弱的）,最後又花了一天時間來找本身程序的bug。

自測

       本身程序的bug大多數是由於課下測試不充分，沒有按照分支樹去構造樣例，而是經過本身對本身程序的瞭解，在腦中構造可能會出錯的樣例，進行測試，而且在構造樣例時，一些邏輯性不強的部分是經過邏輯來進行檢查處理的，並無構造簡單的樣例去進行測試，這樣也許一些較爲低級的錯誤就不易被發現，而邏輯複雜的錯誤又沒有想到，而後就gg了。

互測

       進行格式測試， 若是對方用的是正則表達式，我會先檢查其正則表達式，不然的話再根據分支樹進行測試。

       進行功能測試，先是簡單的進行基本功能測試，再進行邊界測試，壓力測試，在這幾回測試中都找到了對方的Bug。在測別人程序時，我曾嘗試去看懂對方的代碼，從而在邏輯上找到錯誤，但並非每一個人寫的程序都那麼好懂，看了三份也就只找到了一個bug，但能夠大體上知道對方的思路，從而學習借鑑思想和方法。

 

3、第一階段總結

　　記不得是誰說過的一句話了「人生就是不斷的否認昨天的過程」，每當回看的時候老是會發現問題，而這些問題倒是當時很難發現的，這也就說明了總結的重要性了。

　　. 類圖仍是提早畫畫比較好，會使結構更加清晰；

      . 設計是要佔用大量時間的，每次最難的地方也就是設計了；

      . 多和大佬交流交流，但並非說不動腦思考，而是學習好的方法和思路；

      . 課下測試根據分支樹進行測試，但並非說分支樹就必定是全面的，測試是個無限逼近的過程吧，多測測總沒壞處，尤爲是邊界問題；

      . 設計代碼結構的時候應該想到可擴展性，要否則後面可能會走的很難；

      . 不斷的總結錯誤，改善代碼，其實發現每當要添加新的需求的時候才發現原來代碼的一些問題，設計問題或是風格問題等等；

　附上本身每次作OO 的過程：第一件事就是先學習該部分的理論知識；第二件事就是研讀指導書，看客服羣和issue上的討論，盡力達到對指導書要求的深入全面的理解，但卻也是很容易心累的事情了QAQ；第三件事是構思本身程序，畫出類圖，屬性方法，以及類之間是如何交互的。

　　感謝OO，打不死你的都讓你變得更增強大！