關於面向對象第一階段的總結

　　從面向過程編程向面向對象編程的過渡基本上是每一個程序猿的必經之路，在我印象裏面，面向對象是一個和常規思惟相沖突的方法，一切事物皆對象，經過面向對象的方式，將現實世界的事物抽象成對象，現實世界中的關係抽象成類、繼承，幫助人們實現對現實世界的抽象與數字建模。經過面向對象的方法，更利於用人理解的方式對複雜系統進行分析、設計與編程。同時，面向對象能有效提升編程的效率，經過封裝技術，消息機制能夠像搭積木的同樣快速開發出一個全新的系統。

　　而在此次面向電梯編程做業中，我已經被oo這門課的坑震驚到了：

　　從最開始的多項式計算開始我已經感受到了一絲掛科的氣息//滑稽，oo將做業與現實工程緊密結合，程序的魯棒性是咱們在數據結構和計組裏面從未考慮過的，反正程序crash是不可能crash的，就算大佬爆棧也是不可能crash的。在多項式計算程序設計的時候，程序的容錯處理倒是整個設計裏面最讓人頭疼的問題，合法格式否？關鍵字完整否？數組溢出否？int溢出否？互測階段可能出現的各類刁難都是須要考慮在內的。固然，雖然這樣的課程設計很是坑，都是和工做後的程序設計也是很像，程序的輸入流充滿了不肯定性，任何一個意料以外的輸入流均可能帶來意料以外的結果。

　　第二次做業正式直面電梯，電梯相較於多項式而言更加適合面向對象方法的使用，樓層類、電梯類、請求處理隊列等等都是很適合將其做爲對象來處理的。不過電梯問題的複雜度也比多項式要高不少。

　　第二次做業還有第三次做業的類圖大概如上所示，Input類處理輸入，AskDisposeOverride是對第二次做業AskDispose的繼承，而AskQueue包含main方法，儲存請求隊列。Bug分析：幾個類的工程量差別較大，AskQueue只須要實例化對象和開數組存數據便可，而AskDisposeOverride類代碼量較大，我對電梯問題的分析和指導書徹底同樣，以主請求捎帶子請求的方式來遍歷請求隊列，因爲電梯內請求和樓層請求的不一樣，須要分類討論的代碼部分不少，極易產生少寫漏寫等問題。另外此次我終於明白輸出格式是一件很是很是很是重要的事情，在輸出格式上翻車實在是太遺憾了。而在互測環節分析其餘同窗的bug的時候，抽到的只有大佬和萌新的代碼，有點代碼寫得無可挑剔找不到bug，有點代碼連指導書的基本要求也達不到。在互測的過程當中發現你們仍是比較側重於「溢出bug」的檢測，能夠先查看互測代碼中各個數組的大小再花樣嘗試各類數組溢出狀況。
　　在這三次的做業中仍是發現本身的代碼通常低級bug較多，好比輸出格式啥的=_=，在之後的做業裏面仍是要be patient。