OO第一次blog總結作業 

前言

答題判題程序：針對與pta上的3次作業，主要考察的是javabean類的設計，類與類之間存在的聯系的設計以及正則表達式的學習與書寫。除了第三次作業的測試點不完善需要一個一個自己去猜測試點外，大體設計上是不難的，題量也是規規矩矩（其實除了最后一題，其他都是送分題的:)）。最重要的是在第三次作業當中，是無法理解一些測試點的得分要素的，在這次作業中得了97我感覺是十分的不容易的，特別的最后一個測試點死命就是測不出來，感到有些絕望。對于一直貫穿三次作業最重要的我覺得是judge方法，以下會對其進行一些說明補充。

設計與分析

第一次作業

類圖：

耦合度：

由于改題目較為單一簡單，只是對單一題目的判斷正誤，我就只設計了一個除Main類外的Question的javabean類。然后用switch來接受輸入的line信息然后逐一進行信息處理，然后主要的判題過程與以及switch過程，我都是寫在Main當中的，因為比較簡單第一次作業，所以思路也是迸發出來，一股腦就將作業寫完了，導致Main類中的耦合度較高。

第二次作業

類圖：

耦合度：

第二次作業完善了試卷類以及答卷類。這次的作業因為設計到了多張試卷以及答卷的情況，所以使用了大量的集合來存儲信息，在試卷類中也采用了集合來封裝問題。每個試卷對象都可以用ArrayList集合來存儲題目類創作了使每張試卷對象都可以擁有獨立的題目，在此之前也是在Main中創建了questions的集合，所以可以通過題號來找到題目，以此來創建試卷對象。關于空格問題，我覺得這是這次作業中最有挑戰性的一個難題（其實歸根結底就是對正則表達式的抉擇），因為可能會存在不規范輸入，所以我們要屏蔽空格帶來的干擾，并從line輸入中匹配出有效的信息。

最后在第一次作業的基礎上我對判題過程以及輸出過程都寫成了一個judge方法，但可能嵌套過多，思路耦合嚴重導致復雜度比較高的，對比第一次作業大體上是沒有太大改變的。

第三次作業

類圖：

耦合度：

這次的作業是前兩次作業的綜合，相較于第二次作業難度是直線上升的。暫且不談測試點多且分類較為散列，而且測試點的提示不夠明顯，雖然知道這涉及了現實中客戶的需求大多數情況下會描述不清，需要我們去猜測（但還是能夠理解的:)）。

1.這次作業增加了學生的學號和姓名以及刪除題目這一功能。這其實還是比較好添加的，我只要創建一個新的javabean類的Student類并且在Main中繼續用ArrayList去裝載從輸入信息中讀取到的學生信息。

2.其次還有相對于第二次作業更加豐富化的錯誤格式判斷，由于相對于第二次作業錯誤判斷的單一及這次作業的復雜化，我對錯誤格式判斷也是添加了isWrong的方法去判定輸入的line，這里是涉及了更加細致化的正則表達式的判定并且需要自己去摸索，這里是耗時比較高的。

3.針對第三次作業的輸出更加細致化和對題目會有可能刪除和引用錯誤的可能出現，也是在Main中建了一些集合來裝載，并且有相應的方法去判斷并在judge的核心方法中去實現判斷后輸出不同的結果。

4.最后完善了答卷類。我在這里面加了一個學生對象的屬性作為答卷人，這個是需要從Main中的學生集合中去搜索的，否則輸入not fine。

踩坑與心得

踩坑

第一次作業的坑點

這里的坑點是比較少的，我甚至不知道我這個算不算坑點:)。當我看到這個樣例7中的#N: 1 #Q: 5 +5= #A:10的時候，我一開始就覺得這道題不簡單了，可能會涉及到很多的輸入格式判斷問題的出現，于是乎我便用了好多的正則表達式去不斷地匹配啊。（由于是第一次作業，說實話正則表達式在當時是比較懵逼的，可以說的聞所未聞）到了提交完后看到滿分也是比較開心的（功夫不負有心人的），但是舍友卻告訴沒必要考慮那么多時（:)心里也是晴空霹靂）。總的來說，題目邏輯時非常的簡單的，沒什么好講的，畢竟這才是第一次作業，難度偏低，當時也只是多想了一些東西的而已，但我沒想到的時在后面給了節省了很多時間的。

第二次作業的坑點

這里相較于第一點我踩了兩個坑點

1. 出現了集合訪問越界問題（這是一個比較常見的問題了）

我的解決方法如上圖所示，每當給AnswerPaper答卷類添加問題給Integer類型的score集合時，未給該題目賦予分值（在未答題的情況下是都賦予0的）

1. 一開始我是為Question題目類的每一個題目對象都賦予了分數score的成員變量的，后來才發現每一張試卷的題目所給予的分數都是不一樣的，才從該類中刪除了score這個成員變量并且在答卷類AnswerPaper中用了ArrayList來裝所有的成績

第三次作業的坑點

講到這里，也只剩下:) 因為坑點是比較多的而且考慮的東西也是指數級遞增

1. 從一拿到題目開始，題目相較于前兩次作業已經是大變樣了，我感覺。我一度認為可能我的代碼要大改了，因為前面的架構沒有搭建完善。

考慮的東西（審題）：

1. 首先我想到的是大改了對輸入格式的判定

我就在想我這個獲取第二個字符（就是#后面的那個字符，是判斷輸入line的類型的標志）會不會被好多個空格給我隔開，導致我輸入的line第二個字符不是類型判斷標志（這是我當時最后怕的地方）。

1. 其次我想到的是如果我的問題在加入題庫之前會不會出現在這之前有試卷出現過這道題目，那這道題目到底算是不存在還是存在呢，在這里也是遲疑了蠻久的。好在后面老師提醒了不會出現這種情況我才放心書寫代碼。
2. 最后就是總分的計算。這里有兩個地方沒表述清楚，一是關于被刪除題目要不要算進總分中，二是引用錯誤的題目要不要算進總分內。我是十分的不理解的，好在后面有同學的指點：（這道題目既然出在了試卷上，說明總分已經加上了這道題目的分數了的），也是恍然大悟。
3. 從這里開始我就已經開始提交代碼了一提交好家伙28個測試點，一開始我只是拿了部分分還有5個測試點并沒有通過，一個是isWrong方法中對錯誤輸入格式判斷有一個沒有拿分，于是我仔細往回找，終于是拿到了這3分。

還有兩個是空字符的兩個測試點，我在想啥是空字符啊，空字符不就是沒有問答這個問題嗎？answer is null？？？為什么我沒有得分呢，我考慮了很久，我一直以為是正則表達式出了問題。后來在查閱了一些資料后我才知道了啥是空字符和null之間的區別（頓時覺得自己好(′д｀ )）

最后兩個測試點是若在答案中出現空格應該要屏蔽的情況，我這里是沒有拿到分的，是在該作業結束狗去問滿分的同學才知道的，在后面的補練當中也是成功獲得了滿分。

心得

在前兩次作業中其實乍一看是沒啥大問題就是豐富了自己的代碼經驗。而第三次的作業是真的難度飆升，我感覺提升最多的就是對正則表達式的理解以及知道了其對字符串的作用是有多么的巨大，對我們這些程序員的是多么鋒利的利劍。明白了空字符“”以及null的區別。更懂得了團結合作的精神（:)當然我指的不是去抄襲，而是互補，相互的分享自己對測試點的探索經歷和測試點的猜測）。

改進與建議

減少耦合度，要求盡可能地減少類之間的依賴從而使得代碼更容易維護和擴展，可以仔細設計代碼模式來解耦。這是我從我的類圖和耦合度分析圖當中得到的結論以及相處的方法建議。其中最有說道的就是judge方法了，這個方法是貫穿了我所有思想和功能的方法，我把好多東西都塞進去處理了并且有三重循環以及各種的if else判斷。在這之后我會先分析畫出類圖之間的關系后，再去寫代碼，盡可能做到可單一功能的原則。

總結

從C語言到java，意味著從面向過程到面向對象。這其中的跨度是可以想象的，這是一種從思想思維方面的轉換。在這3次的pta的作業當中，其實體會最深的就是oop面向對象的思維體現。所以我知道了面向對象編程的重要性：通過完成大作業，我深入理解了面向對象編程的核心概念，包括類、對象、繼承、多態等，意識到了它們在軟件開發中的重要性。完成大作業是一次實踐編程技能的過程，通過實際動手編寫代碼，加深了對編程語言和相關工具的熟悉程度，提高了編碼能力。完成這次作業的路途是艱難的，但它會給予我成就感和自信心，激勵我繼續努力學習、不斷進步。（如果可以的話，望老師手下留情，可以適當多給我一些樣例:)）。