OO前三次做業總結

很慶幸我還活着……

千言萬語盡在一言中……

好了話很少說直接進入正題，在此對前三次OO做業作一個簡單的總結：

第一次做業：第一次接觸面向對象…做爲一個沒有java編程基礎的小白來講，面對這個原本比較簡單的做業仍是比較頭疼的，首先不懂java語法，其次不理解面向對象的含義；一臉懵逼……

好在通過兩天的煎熬以後也算是勉強入門了，磕磕碰碰寫完了第一次做業，因爲初次第一次對於面向對象這個概念沒有多少理解而且做業難度也不大，因此整個程序只有一個類，代碼量110行；主要難點爲輸入是否合法的判斷以及多項式算法的選擇，多項式合法性判斷採用和了正則表達式，可是一開始使用的正則表達式進行一次判斷故沒有經過壓力測試，第二次將正則表達式判斷拆分爲兩個部分，成功解決了該問題，算法爲先將全部項進行合併，而後排序，最後將指數重複項相加，最後順序輸出；

公測：因爲閱讀指導書不夠仔細，忽略了一個多項式指數不能重複的要求，因此公測中指數重複分支錯了一個樣例；

互測：未被發現BUG，對於本身的測試任務，按照分支樹的要求逐一進行測試，並閱讀程序代碼思考是否存在漏洞，最後並未發現BUG；

 

 

第二次做業：

第二次做業的難點主要在於同質請求的判斷，一開始因爲對此理解不夠準確，採用了直接與前一條請求進行對比的方法，故進行了一次重構改進，按照指導書的要求建立了八個類：elevator , floor , scheduler , commandqueue , command , judge , allcommand , elevatorsystem 。

elevator類：描述電梯的各類行爲及屬性，包括髮送請求，開始執行請求，結束請求，更新電梯狀態等；

floor類：描述樓層的行爲及屬性，主要爲上下行按鈕，發送請求，結束請求；

scheduler類：進行電梯系統的調度；

command類：包含一條請求的各類屬性，好比輸入請求的字符串，請求類型，請求樓層，請求時間等；

commandqueue：描述等待執行的請求隊列的屬性及行爲，如隊列內請求數量，隊首隊尾，入隊出隊；

allcommand：包含全部輸入的請求；

judge：包含對輸入請求進行各類判斷的方法；

elevatorsystem：主類，調用各個類運行電梯系統；

公測：未被發現BUG；

互測：經過閱讀測試代碼發現其未對主類一些可能發生異常的語句包含在try中，由此發現了一個crash錯誤；另外發現一條與指導書不符可是README並未作出聲明的狀況，算做一個BUG。

 

第三次做業：

主要在第二次做業的基礎上增長了捎帶功能，因爲我第二次的設計採用了以電梯及樓層按鈕規劃電梯行爲的方法，故第三次做業並未作出太大的改動，主要的改動爲在判斷請求是否須要加入請求隊列以前先（根據電梯及樓層當前按鈕狀態）判斷該請求是否能夠捎帶，若不能捎帶則進入請求隊列，若不能則進入請求隊列；另外在電梯類中加了目標樓層及下一個停靠樓層兩個屬性，並在每次發送請求的時候將這兩個屬性進行更新；其他都是細節上的微小變更。

公測：未被發現BUG；

互測：並未發現他人BUG；

　　因爲README描述不夠嚴謹，關於前零數量被發現一個BUG，未被發現功能性錯誤；

 

感想：從一個月前幾乎一竅不通的小白到如今，三次OO之旅仍是讓我很有感觸；

一、首先在心態上：

（1）寫代碼時的心態：寫代碼實際是一個比較枯燥的過程，因此這更加要求咱們要保持一個心靜的狀態，尤爲是當你束手無策不知所措時，沉住氣不驕不躁是高效解決問題的最重要前提；

（2）、互測時的心態：拿到他人的代碼，找BUG當然是直接目的，可是別忘了這種制度的根本目的是在於在閱讀代碼互相測試的過程當中相互學習，所以僅以鑽牛角尖的形式其實並不能讓咱們有所收穫；反過來，當被他們測出BUG時，也要擺正本身的心態，如若確實是存在那樣的問題，即便該問題比較刁鑽，也應該虛心接受，否則怎麼叫面向對象呢……

二、關於調試的感想：

（1）、部分同窗由於測試不充分致使本身寫完了感受沒有任務問題，到了互測階段就要被挑出BUG，其實根本緣由在於你始終站在本身的角度去作測試，作測試時關鍵在於把本身看成一個客戶，你面前這個代碼是你須要使用的程序，而你是一個要求很是高很是刁鑽的使用者，因此你會想盡各類辦法找出程序的漏洞，或者經過README發現其說明與程序功能自相矛盾的地方，這樣作，至關於你在互測以前已經進行了一次互測，而測試者正是你本身；

（2）、善用調試技巧，不論是輸出調試也好，單步調試也罷，調試技巧在測試中顯得尤其重要，當你發現一個BUG，可是又不能快速的發現這個BUG具體是由什麼形成的，盯着本身的代碼發呆則是大忌，是一種事倍功半的作法，此時善於使用合適的調試技巧纔是正解；

三、想要寫出一個真正面向對象的代碼，就必須完全拋棄面向過程的風格，第一次做業因爲難度小代碼規格也較小這一點並明顯，可是隨着要求和代碼量的提升，曾經那種面向過程的編程風格註定要被完全拋棄，最重要的一點在於——減少耦合度，減少耦合度，減少耦合度，你所寫的一個類，雖然在程序正常運行時與其餘類存在或多或少的關聯，可是當撇開系統的功能僅僅閱讀這一個類時，它應該能夠成爲一個幾乎徹底孤立的示例；

最後感謝給予咱們莫大幫助的老師及助教，預祝後程OO之旅一切順利。