第二次blog總結

23201314-郭粮源發表於2024-06-07

目錄
  • 一.前言
  • 二.設計與分析:
  • 三.踩坑心得
  • 四.改進建議
  • 五.總結

一.前言

第四次大作業:
1.題量:這次的大作業有三道題,題量較少。
2.難度:第四次大作業的核心題目答題判題程式-4是經過了三次對第一次答題判題程式為基礎的迭代而成,難度毋庸置疑,而且因為第一次總結,這次大作業距離上一次大作業也有很多天,我對我的程式碼也多了很多陌生的感覺,我覺得難度是大的,至少對於我來說難度是大的,我這次大作業也沒有拿到多少分。覺得很遺憾,但我也會在作業後再次花時間去熟悉,去解決。
3.知識點的使用:
第四次大作業使用了以下Java知識點:
這段Java程式碼是一個考試系統,用於管理考試問題、學生答案、評分和輸出結果。以下是程式碼中使用的一些關鍵Java知識點:
(1). 類和物件:程式碼定義了多個類(Question, text, Student, AnswerSheet, Main 以及內部類 wd),並建立了這些類的物件。
(2). 封裝:每個類都封裝了資料和行為,例如 Question 類封裝了問題編號、內容、標準答案和有效性狀態。
(3). 繼承:雖然程式碼中沒有顯示繼承的使用,但Java中的所有類都隱式地繼承自 Object 類。
(4). 內部類:Main 類中定義了一個內部類 wd,用於儲存一些特定的資料。
(5). 靜態成員:在 Main 類中使用了靜態 Map, List, Set 等來儲存和管理學生、問題、答案等資料。
(6). 雜湊:使用了 HashMap 來利用雜湊實現快速查詢。
(7). 資料結構:使用 MapList 作為主要的資料結構來儲存和運算元據。
(8). 正規表示式:雖然程式碼中沒有直接使用正規表示式,但在解析字串時可能會用到。
(9). 模組化:程式碼被組織成多個類和方法,易於維護和擴充套件。

第五次大作業:
1.題量:這次的大作業有三道題,題量較少。
2.2.難度:第五次大作業是繼前四次迭代大作業結束後的新的迭代式大作業家居強電電路模擬程式,新的程式專案,新的開始,這次大作業的難度相較簡單,但比第一次大作業是要難的。老師也在大 作業題目上先說明了大作業
3.3.知識點的使用:
4.第五次大作業使用了以下Java知識點:
(1). 類和物件:定義了多個類(Device, Switch, SteppedSpeedController, ContinuousSpeedController, Blight, Rlight, Fan, DeviceController, Main),每個類都是一個藍圖,用於建立物件(例項)。
(2). 繼承:Device 是一個抽象類,它定義了一些基本屬性和方法,而 Switch, SteppedSpeedController, ContinuousSpeedController, Blight, Rlight, Fan 等類繼承自 Device 類,擴充套件了其功能。
(3). 封裝:每個類都封裝了自己的屬性和方法。例如,Device 類封裝了裝置ID、輸入電壓和輸出電壓。
(4). 多型:Device 類中的 setVoltage()display() 方法被不同的子類以不同的方式實現,展示了多型性。
(5). 抽象類:Device 類是一個抽象類,它不能被例項化,但可以作為其他類的基類。
(6). 介面:雖然程式碼中沒有直接使用介面(interface),但是 Device 類的抽象方法可以看作是一種介面的定義。
(7). 集合:使用了 MapList 集合來儲存和管理裝置及其連線。
(8). 正規表示式:在 DeviceController 類的 interpretControls 方法中,使用了 PatternMatcher 類來解析控制字串。
(9). 異常處理:程式碼沒有顯示異常處理機制,但在實際應用中,對輸入電壓的調整和裝置操作可能需要異常處理。
(10). 方法重寫:子類透過重寫父類的方法來改變其行為,例如 display() 方法在不同的子類中有不同的實現。

第六次大作業:
1.題量:這次的大作業只有一道題,題量少。
2.2.難度:第六次大作業是繼第五次大作業家居強電電路模擬程式的第一次迭代,雖然只有一道題,但結果就是得分的佔比全部拉到了這次的核心作業:傢俱強電電路模擬程式-2.難度也是相較於第一次的基礎難了不少。
3.3.知識點的使用:
4.第六次大作業使用了以下Java知識點:
這段Java程式碼演示了一個電子電路模擬系統,涉及到多個關鍵的Java程式設計概念:
(1). 抽象類:Device 類是一個抽象類,定義了所有裝置共有的屬性和方法,比如電壓針腳、電阻和重新整理裝置狀態的方法。
(2). 繼承:Toggle, SteppedSpeedController, ContinuousSpeedController, Blight, Tlight, Fan, StandardFan 等類繼承自 Device 類,實現了具體的裝置行為。
(3). 封裝:類封裝了屬性和方法,隱藏了內部實現細節,只暴露了必要的介面。
(4). 多型:Device 類中的 refreshDeviceState()displayStatus() 方法在不同的子類中有不同的實現,體現了多型性。
(5). 集合框架:使用了 List, Set, Map 等集合類來儲存和管理裝置物件。
(6). 泛型:集合類如 ArrayList, HashSet, LinkedHashMap 使用了泛型來確保型別安全。
(7). 異常處理:程式碼中沒有顯示異常處理,但在實際應用中,解析輸入或執行操作時可能需要異常處理。
(8). 正規表示式:程式碼中沒有直接使用正規表示式,但在解析複雜字串時可能會用到。
(9). 方法重寫:子類透過重寫父類的方法來改變其行為。
(10). 並行和序列電路:SerialCircuitParallelCircuit 類模擬了電子電路中的序列和並行連線方式。

二.設計與分析:

對於第次大作業,新增加了輸入選擇題題目,填空題題目的分別,而且在選擇題上增加了多選題的分類,導致輸入方式變得多樣,由於判斷方法不同,第四次大作業中,我還新建立了一個判斷類,專門用來判斷題目型別,並且來呼叫特定類的判題方法。也增添了多張試卷分析。而且輸入順序也得到改變。

第四次大作業Source Monitor分析
我對第四次大作業的答題判題順序-4 的程式碼進行了SourceMontor分析生成報表內容。

次大作業,我看到是有關物理的串聯並聯電路問題,首先應該就是先在腦子和草稿紙上模擬我們高中學過的電路問題,這樣思路就明顯清晰很多,建立裝置類為父類,其中分控制裝置的開關或者不同調速器。這個系統較為簡單,只需要考慮串聯就行,預設所有裝置為串聯連結,計算方面只要計算好各個調速器在不同電壓下的開關或速度調控和電器的輸入電壓和輸出電壓之間的電壓差。

第五次大作業Source Monitor分析
我對第五次大作業的答題判題順序-4 的程式碼進行了SourceMontor分析生成報表內容。

次大作業
第六次大作業是第五次大作業的第一次迭代,其相較於第五次大作業,這次增加了一個新電器落地扇,其電壓計算較為簡單,加入到裝置父類的過程也較為簡單。但這次迭代最為核心的是電路增加分成為串聯和並聯電路,其中並聯電路的計算較為複雜些,然後就是輸入裡的電路與電路的連結,我的想法是把電路也看作為電器原件,這樣我們就能把電路作為一個元件進入到輸入的要求裡。

第六次大作業Source Monitor分析
我對第六次大作業的答題判題順序-5 的程式碼進行了SourceMontor分析生成報表內容。

三.踩坑心得

1.第四次大作業踩坑心得:
在第四次大作業中,我對新新增的選擇題中的選擇和單選的判定這方面出現了問題,導致輸出總是為空,我的程式碼的問題可能出現在我程式碼對字串的處理出現了錯誤,在之後我詢問了我的同學,向其請教,他告訴我的邏輯有很大錯誤,並給我發了一個簡易模板,
// 處理單選題 if ("single".equals(question.getType())) { boolean result = question.checkAnswer(answer); results.put(number, result); scores.put(number, result ? testPaper.getScore(question.getNumber()) : 0); } // 處理多選題 else if ("multiple".equals(question.getType())) { String[] correctAnswers = question.standardAnswer.split(","); Set correctSet = new HashSet<>(Arrays.asList(correctAnswers)); String[] userAnswers = answer.split(","); Set userSet = new HashSet<>(Arrays.asList(userAnswers)); boolean isCorrect = correctSet.equals(userSet); results.put(number, isCorrect); scores.put(number, isCorrect ? testPaper.getScore(question.getNumber()) : 0); } }
之後我對判定方法進行重構,方法也得到了改善。

2.第五次大作業踩坑心得:
在這次電路模擬中,我出現了多個錯誤,第一個就是在吊扇轉速的計算時沒有考慮double的精度導致了電壓無法正確分壓,從而導致四捨五入時產生偏差導致整個“開關-吊扇”的測試點無法透過。

class Fan extends Device{
private int speed;

public Fan(String id) {
    super(id);
    this.speed=0;
}
public void setVoltage()
{
    double diffv = Math.abs(pin1Voltage - pin2Voltage);
    updateOutput(diffv);
}
public void updateOutput(double volege)
{
    if (volege < 80) {
        speed= 0;
    } else if (volege > 150) {
        speed = 360;
    } else {
        speed = 80 + (int) (((360.0 - 80) / (150.0 - 80) * (volege - 80)));
    }
}
public String display()
{
    return "@" + id + ":" + speed;
}

}
還有就是我的字串處理我嘗試使用正規表示式去處理字串,但輸入樣例後輸出為空,到最後發現是正則的符號判定我寫錯了。

3.第六次大作業踩坑心得:
第六次大作業的測試點是沒有說明的,我這次大作業也做得很是粗心,沒有認真考慮每一個細節,第一個就是因為在上一個大作業的錯誤下,我沒有完善最佳化開關的狀態改變,導致我輸入後的輸出是錯誤的。第二個就是排序的問題,沒有考慮到輸出的順序,導致輸出的上下是倒置輸出,後來增加了輸出的排序後,輸出得到改善。

最後的輸出還有一個問題就是每次輸出的數值都是0。
比如輸入樣例2,輸出應該是@K1:closed @K2:turned on @L1:1.00 @D1:0 @D2:200 @D3:200但是輸出後的結果D2和D3的數值為0。因為時間的問題,我這個問題還是沒有得到確切的解決,但我猜測是並聯電路的字串處理後的計算出現了問題。

四.改進建議

  1. 程式碼結構最佳化:我的程式碼因為自身想的邏輯太過於複雜,沒有找到簡易的程式碼思路導致程式碼太長,結構多餘複雜凌亂,我希望我以後能夠確保程式碼結構清晰,模組化,遵循物件導向程式設計原則。可以考慮引入設計模式來簡化程式碼並提高可維護性。
  2. 異常處理:加強異常處理機制,確保系統在面對異常情況時能夠優雅地處理,並給出相應的提示資訊讓使用者能夠理解發生了什麼問題。
  3. 效能最佳化:查詢並消除可能存在的效能瓶頸,最佳化演算法和資料結構以提高程式的執行效率。
    4.功能擴充套件:每一次的程式碼都是臨時抱佛腳,導致每一次迭代做的都很複雜費時間,沒有進一步考慮程式碼的後續書寫,我希望我以後能夠考慮是否有進一步的功能擴充套件空間,可以在原有功能基礎上進行創新和擴充套件,使程式碼更具吸引力和實用性。
    5.我應該在寫程式碼之前提前先構思好這一次大作業的基本思路,模擬實際上的作業要求,比如預先模擬好實際電路的構造,去思考邏輯,程式碼架構,需要畫好類圖,否則寫程式碼時就會出現呼叫關係不清晰等問題。

五.總結

收穫:
物件導向程式設計(OOP)的應用:透過設計和實現 Device 類及其子類,您加深了對物件導向程式設計中類和物件的理解,學會了如何使用繼承和多型性來構建程式碼。
電路理論的實際應用:在類比電路行為時,您可能對電路的基本概念,如電壓、電流、電阻和功率等有了更深入的理解。
資料結構和演算法:在處理電路連線和裝置排序時,您可能使用了不同的資料結構(如列表、集合)和演算法(如排序),這有助於提高您的演算法設計能力。
正規表示式的使用:透過使用正規表示式來解析輸入,您可能提高了對字串處理和模式匹配的理解。
程式碼組織和模組化:將功能提取為方法,您可能學會了如何組織程式碼,使其更加模組化和可維護。
問題解決技巧:在解決程式設計中遇到的問題時,您可能鍛鍊了除錯和問題解決的能力。
自主學習:在完成作業的過程中,您可能需要自學新的程式設計概念或技術,這增強了您的自主學習能力。

不足:
程式碼重用性:在程式碼中可能存在重複的邏輯,這表明需要進一步提高程式碼的重用性,例如透過建立更通用的方法或工具類。
輸入驗證:如果程式碼中沒有充分的輸入驗證,這可能導致程式對錯誤或異常輸入的魯棒性不足。
異常處理:程式碼可能缺少異常處理機制,這在實際應用中可能導致程式崩潰或不正確的行為。
效能最佳化:隨著電路規模的增長,效能可能成為問題。程式碼可能需要最佳化以提高效率,特別是在處理大規模資料時。
文件和註釋:每次回頭看程式碼都會有一種陌生感,程式碼中缺少足夠的文件和註釋,這可能會影響我程式碼的可讀性和可維護性。
設計模式的應用:在解決某些問題時,可能沒有充分利用設計模式來提高程式碼的靈活性和可擴充套件性。

相關文章