（1）前言
本次部落格是對前三次大作業的一個總結，第四次是前三次的一個迭代，第五、六次是一個全新的大作業。此次部落格對兩次型別的大作業進行一個總結。
此次比前兩次的題目更加複雜也需要更加嚴密的思維邏輯。這次大作業輸入資訊分為5種：題目資訊、試卷資訊、答卷資訊、學生資訊、刪除題目資訊。資訊可能會打亂且順序混合輸入。需要正規表示式判斷是否滿足格式，只有正確的格式才能進行儲存。首先我們需要按照題目要求儲存所有的資訊，在儲存之前還需要判斷輸入的資訊格式是否正確（需要運用到正規表示式）。然後根據試卷裡的題目進行逐一判斷，判斷時第一步需要從學生的答卷中找尋，找尋成功再去總題庫中尋找然後判斷對錯，再來計算分數。總的來說，此次大作業在前一次的基礎上增加了許多限制條件，難度也更大了。
7-1題目集，主要是針對家庭電路的設計來開展的，考察的知識點主要有：
1.Java的三大特性的體現：封裝、繼承、多型，分別從這三個方面進行編碼，要求我們要合理的去設計我們的程式碼，各個類應該如何去設計，以及各個類之間的關係應該如何去安排。
2.對電路的理解方面，要求我們具備一定的問題理解能力，在第二次迭代中，裡面出現的測試點隱藏了，需要我們提前去設計，而不是像以前一樣根據測試點來完善自己的程式碼，現在對程式碼的設計要求更高了，需要我們提前獨立的去理解和設計電路，並以次來將自己的程式碼設計好。
本次的大作業題量相對上一次來說，不是特別大。難度來說，其實並不是特別的難，這次大作業的難度主要體現在第二次迭代的過程當中，沒有了測試點的提醒，對我們的程式碼設計要求進一步提高了。
(2)設計與分析
第四次Pta大作業：
此次程式碼這一次的新增了選擇題和多選題，總體結構沒有太大的改變，我增加了多個同學有多張不同答卷的情況，需要在輸出時對試卷進行排序。
多選題標準答案是在輸入時將多個結果切割儲存，判斷結果對錯時遍歷這些正確的答案，假如全部正確則是true，錯一個則是false，其他則是輸出partially correct。
在關於對輸出對試卷排序則是在輸出前將答卷先按試卷號從小到大排序，再根據答卷的學號進行第二次排序，這樣答卷的順序就是先學號再試卷號從小到大的順序進行排序了，再按照原來的程式碼邏輯進行輸出就好了。
填空題的給分與正常判分差別不是很大，不是全對的情況下，只要改變判斷是否答案包含在標準答案之中，即可判斷是否是半對還是錯誤。
這個是idea生成的類圖
根據上面的分析，可以明顯的看到Main函式中圈複雜度實在是很高，這就要從上一次迭代說起了，我一直都在把重心放在改程式碼中，並沒有花什麼時間去好好去設計程式碼的整體結構，導致Main函式圈複雜度高，後面想去改，又發現工作量實在是太大，需要大改，拍自己的原有邏輯改變就沒有去改。
現在透過查資料，我知道了以下幾個降低自己圈複雜度的知識點：
1.拆分函式：將主函式中的功能拆分成多個小函式，每個函式負責一個具體的功能，可以降低單個函式的複雜度。
2.減少巢狀：減少巢狀的層數，儘量避免過多的if-else巢狀，可以將條件判斷提取成獨立的函式或使用多型等方式。
3.使用設計模式：合理運用設計模式，如工廠模式、策略模式等，可以有效簡化邏輯，降低複雜度。
第五次大作業
在上一次大作業的教訓下我重新設計了一下結構
資料結構：
建立結構體或類來表示每種裝置，包括開關、調速器、燈和風扇。每種裝置應包含狀態、檔位、亮度、轉速屬性。
定義資料結構來儲存裝置之間的連線關係，使用雜湊表和陣列來儲存裝置之間的連線。
裝置邏輯：
編寫函式來處理每種裝置的狀態變化和引數輸出的邏輯，根據輸入資訊調節裝置狀態和引數。
設計演算法計算裝置之間的聯動關係，確保正確處理裝置之間的連線。
輸入資訊：
解析輸入資訊，包括裝置資訊、連線資訊和調節資訊，將其轉換為程式可處理的資料結構。
針對不同型別的裝置和連線關係，進行合理的資料處理和儲存。
類比電路執行：
根據輸入資訊設定初始狀態，開始類比電路的執行。
根據裝置之間的連線關係和調節資訊，逐步更新裝置的狀態和引數。
輸出結果：
在模擬結束後，根據裝置最終狀態和引數輸出結果，按照指定格式輸出每個裝置的狀態或引數值。
在這次大作業的類的圈複雜度相比與前幾次的來說確實有了相當的改變，但我還是要總結一下這次類設計的不足，一開始我是想將主要的功能函式與方法放到相應的類中，但隨著敲的過程中，我老是控制不住的將在Main中新增一些邏輯，一直都在更改，這才導致了main類中的圈複雜度有點高了。這也是我要接著努力的地方。不過話說回來了，這個階段大作業的強度我也在慢慢的適應了。
第六次大作業
這一次大作業的迭代主要是在對並聯關係的處理和電路的控制這倆個方面進行的，尤其是在電路元件匯眾的時候，開關的處理尤其重要，一不小心就會有很大的問題，這一次大作業，我又重新推翻了重寫了一遍，花了好多時間去修改。設計的大致思路和上一個大作業的思路基本一致，這裡就不多贅述了。
下面是類圖
這一次的圈複雜度進一步降低了，這一次我用一個類專門去封裝資料，在輸出的時候，我用了treemap進行排序，減少了我的程式碼量，下面是用了一個介面對輸入的hashmap進行排序
class CustomComparator implements Comparator
@Override
public int compare(String s1, String s2) {
char type1 = s1.charAt(0);
char type2 = s2.charAt(0);
Map<Character, Integer> orderMap = new HashMap<>();
orderMap.put('K', 0);
orderMap.put('F', 1);
orderMap.put('L', 2);
orderMap.put('B',3);
orderMap.put('R',4);
orderMap.put('D',5);
orderMap.put('A',6);
// Compare types
int compareType = Integer.compare(orderMap.get(type1), orderMap.get(type2));
if (compareType != 0) {
return compareType;
}
return s1.compareTo(s2);
}
}
這個是真的好用！
(3)踩坑心得和總結
程式碼在提交過程中出現的問題：由於第七次大作業沒有測試點的提示，對我們的要求也進一步提高了，這一整個大作業週期，我都感覺自己一直都在為了改程式碼而寫程式碼，就是一種都在縫縫補補，先設計好一個框架再來打程式碼顯的尤為重要，因為之前的大作業並不特別需要設計特別多類與類之間的關係，只要打得去就可以解決，現在好了，就是因為我在打程式碼之前沒有設計好程式碼結構，讓我走得異常艱難，真的不怕笑話，我最後一次的大作業，我推翻過四五次，楞是沒有好好設計程式碼，直到最後那一次推翻重寫，我從認真地去了設計了一下，不然都過不了。
得出經驗：在以後，無論是大作業還是專案，都要提前去設計，不然真的好浪費時間，還做不出什麼效果來。