JAVA第二次大作業blog

一、前言

---

這一次是有關三到六次的PTA大作業的分析。經過一段時間的學習，我迎來了JAVA的第二次大作業。這不僅是對我所學知識的一次檢驗，更是一次將理論與實踐相結合的機會。
在知識點方面，這三次題目集深入考察了我們對繼承與多型的理解和應用。我們需要深入理解這兩個概念的基本原理，並能夠在實際程式設計中靈活運用它們。透過深入理解並應用繼承和多型的思想，我們可以編寫出更加高效、靈活、可擴充套件的程式碼。
在題量方面，這次三次題目集相較於之前的上三次，明顯展現出了數量上的縮減趨勢。然而，這一減少並非意味著學習內容的簡化或放鬆，相反，這些題目集在難度上進行了相應的提升。第四，五次題目集含有三道題目，第六次則就只有一道題目。
在難度方面，第四次題目集第一題是基於上三次的迭代而來，難度不算太大，但是也並不算容易，而後兩次的題目集則是新的一類題型，第五次題目集只是串聯電路，難度不大，但是還有一些細節要注意，第六次題目集則是加上了並聯電路，難度增加不少。

---

二、設計與分析

---

答題判題程式-4

這道題目是前三次題目集的迭代，它不僅繼承了前三次題目集的核心考察點，還在難度上進行了進一步的提升。它在題目型別、輸入格式、評分機制和處理邏輯等多個方面進行了全面的改進。透過這道題目不僅能夠鞏固和擴充套件我的程式設計知識，還能夠提高問題解決能力、邏輯思維能力。

PowerDesigner中的類圖

這一次的題目集新增了多選題與判斷題，在之前的問題類的基礎上，新增了三個類繼承問題類，新增了一類用於判斷輸入內容與輸出。
這是PowerDesigner中的類圖。

sourcemonitor中的報表

由此分析：
程式的平均複雜度為2.85，各個方法的平均複雜度是相對較低的，但最大複雜度為14，這說明至少有一個方法的複雜度是相對較高的。這可能導致程式碼難以閱讀、理解和維護，同時也可能增加出錯的風險。此外最大塊深度達到9層以上，平均塊深度為5.79。深度過大的程式碼塊通常意味著複雜的邏輯結構，需要最佳化以提高程式碼的可讀性和可維護性。

不足之處：

1. 方法呼叫次數高達163次，這表明程式碼中存在大量的方法呼叫。雖然這在一定程度上體現了程式碼的模組化特性，但過多的方法呼叫也可能導致效能下降和程式碼耦合度過高。
2. 檔案中共有13個類和介面，平均每個類包含4.23個方法。這一指標反映了程式碼的模組化程度，但過多的類和介面也可能導致系統複雜度增加。

改進方案：
將多個方法呼叫合併為一個批次處理操作，那麼可以減少方法呼叫的次數。檢查程式碼中是否存在可以合併或消除的方法呼叫。

家居強電電路模擬程式-1

這次題目集進行了修改，改成了電路，我們需要根據給定的電路連線資訊以及控制裝置的狀態資訊，來模擬並計算出每個智慧裝置在電路中的實時狀態。值得注意的是，這個特定的場景假設電路中沒有電阻元件，因此傳統的分壓計算方法並不適用。這個程式設計挑戰要求我們能夠深入理解電路的基本概念和原理，並能夠靈活運用程式設計技術來解決實際問題。同時，它也需要我們具備一定的創新和解決問題的能力，以便在沒有電阻元件的電路中找到合適的模擬方法。

PowerDesigner中的類圖

這是第一次編寫電路類題目，設計的類比較簡單。
這是PowerDesigner中的類圖。

sourcemonitor中的報表

SourceMontor的生成全部報表圖

由此分析：
從平均方法宣告數量和平均複雜度來看，大多數檔案的值都相對較低，應該警惕過低的複雜度可能意味著程式碼的功能性不足或缺乏足夠的錯誤處理機制。其中以“Test.java”檔案為例。

不足之處：

1. “Test.java”檔案包含了4個類和介面，且每個類平均有12.25個方法。程式碼註釋百分比僅為0.7%，這是一個需要關注的地方。註釋對於提高程式碼的可讀性和可維護性至關重要。
2. “Test.java”檔案的平均每行程式碼複雜度為2.34，最大複雜度達到了20，且存在最大深度為4.75的程式碼塊。這些數字表明該檔案在某些地方可能存在較高的複雜性。

改進方案：
將過長的方法拆分成更小的、更具體的子方法，以提高程式碼的可讀性和可維護性。引入適當的設計模式來簡化複雜邏輯，提高程式碼的可重用性和可維護性。

家居強電電路模擬程式-2

這次題目集相較於上一版本，此次更新特別引入了並聯電路的處理邏輯，也增加了電阻的計算方法，不再是簡單的運算，而是需要運用並聯電阻的特定計算公式來確定總電阻，這增加了程式碼的複雜性。相比於上次的題目集，我們需要精心規劃一個類層次結構來代表電路的不同組成部分。這個層次結構將包括用於表示控制裝置、受控裝置、串聯電路和並聯電路等元素的類。

PowerDesigner中的類圖

這次在原有類的基礎上新加了串聯電路類與並聯電路類以及一個新的風扇類。
這是PowerDesigner中的類圖。

sourcemonitor中的報表

SourceMontor的生成全部報表圖

由此分析：
程式碼中存在較多的條件判斷和分支結構，這可能會導致程式碼難以理解和維護。從類的數量和方法數量來看，大多數檔案的模組化程度適中，但仍有改進空間。其中以“Test.java”檔案為例。

不足之處：

1. Test.java的分支語句百分比達到了25.5%，相對較高。過多的條件判斷和分支結構不僅會降低程式碼的可讀性，還可能導致潛在的邏輯錯誤。
2. 方法呼叫語句數高達135次，顯示出該檔案的模組間耦合度較高。高耦合度可能導致程式碼難以維護和擴充套件，因為一個模組的變化可能需要其他多個模組進行相應的調整。

改進方案：
透過定義清晰的介面，讓不同的模組透過介面進行通訊，而不是直接依賴對方的實現細節。重新審視程式碼中的條件判斷和分支結構，看是否有可以簡化的地方。

三、踩坑心得

1、答題判題程式-4

這是前三次題目的迭代，基於上三次的經驗，對前面的程式碼進行了大量的修改，新加了一個類用於判斷輸入內容與輸出，其中提取內容換成了正規表示式。相比於上次結果要稍微好，。但仍有些錯誤找不到原因。

2、家居強電電路模擬程式-2

這是第一次編寫有關電路的程式碼，只有一條串聯電路相對簡單，但仍有些問題，由於編寫程式碼時為了方便將開關輸出引腳電壓預設為零，而忽視了將開關放在後面的情況。

3、家居強電電路模擬程式-3

此次題目集新加了並聯電路難度較大，在編寫程式碼時遇到了許多問題。

• 在編寫改變電壓時企圖透過引腳類中的方法來不斷遞迴將所有電壓值更改，最終導致除錯時呼叫太多難以看懂。

點選檢視程式碼

public void setVoltage(double voltage, double current) {
		this.voltage = voltage;
		for(Load load :loadList)
		{
			if(load.getInputpins()!=null)
			{
				if(load.getInputpins()==this)
				{
					if(load instanceof ControlledLoad)
					{
						ControlledLoad controlledLoad = (ControlledLoad)load;
						controlledLoad.changeOutputpins(current);
					}
					if(load instanceof ControlLoad)
					{
						ControlLoad controlLoad = (ControlLoad)load;
						controlLoad.adjust(current);
					}
					if(load instanceof Seriescircuits)
					{
						Seriescircuits seriescircuits = (Seriescircuits)load;
						seriescircuits.compute(current);
					}
					if(load instanceof Parallelcircuits)
					{
						Parallelcircuits parallelcircuits = (Parallelcircuits)load;
						parallelcircuits.energized(current);
					}
				}
			}
		}
	}

• 忘記將開關初始電阻設為無限大，而導致出現錯誤。

點選檢視程式碼

public Switch(int num) {
		super(num);
		resistance = Double.POSITIVE_INFINITY;
	}

• 各個負載的更改電壓透過電流去計算，但是更改控制電路卻忘記更改電流導致出錯。

點選檢視程式碼

public void adjust(double current,int flag){//該方法實現對輸出引腳電壓的更改
        switch(gears)
        {
            case 0:{
            	current=0;
                outputpins.setVoltage(0,current);
                break;
            }
            case 1:{
            	current=current*0.3;
                outputpins.setVoltage(inputpins.getVoltage()*0.3,current);
                break;
            }
            case 2:{
            	current=current*0.6;
                outputpins.setVoltage(inputpins.getVoltage()*0.6,current);
                break;
            }
            case 3:{
            	current=current*0.9;
                outputpins.setVoltage(inputpins.getVoltage()*0.9,current);
                break;
            }
        }
    }

四、改進建議

針對以上問題和心得，我思考出以下改進建議：

1. 透過合理的演算法和資料結構設計來減少不必要的方法呼叫，提高程式的執行效率。透過重新組織程式碼的流程和控制結構，我們可以減少不必要的巢狀層級，使程式碼結構更加扁平化。這不僅有助於提高程式碼的可讀性，還有助於提升程式碼的執行效率。
2. 使用依賴注入來管理模組間的依賴關係，使得模組可以更容易地替換和測試。透過將依賴關係外部化，可以使類更專注於自己的核心職責，而不是關心如何建立和配置它的依賴項。這有助於降低類之間的耦合度，提高程式碼的可維護性。
3. 定義清晰的介面和抽象類，透過介面定義模組間的互動方式，降低具體實現之間的耦合度。使用抽象類作為基類也可以降低耦合度。子類可以繼承抽象類並擴充套件其功能，而不需要關心其他模組的具體實現。這樣，我們就可以在不改變現有模組的情況下，輕鬆地新增新的功能或修改現有的功能。
4. 將複雜的函式拆分成多個小的、功能單一的函式。這種做法可以顯著減少單個函式的複雜度，使程式碼更易於理解、測試和維護。

五、總結

在完成這三次大型專案的過程中，我深刻地認識到了程式設計的複雜和魅力。我認識到，只有透過不斷地學習和深入思考，我才能準確理解並實現題目所要求的功能。同時，我意識到，程式設計不僅僅是一種技術，更是一種解決問題的思維方式。它要求我具備嚴密的邏輯分析能力、整潔的程式碼編寫風格以及持續學習的心態。透過不斷地學習和思考，我逐漸培養了這些能力，並在程式設計的道路上越走越遠。在類結構的設計上，我學會了如何根據電路中的實際元素抽象出合理的類，並定義它們之間的關係和互動方式。這不僅提高了程式碼的可讀性和可維護性，也使得程式的邏輯更加清晰。完成這三次大型專案的過程中，我深刻體會到了程式設計的複雜性和挑戰性。我認識到程式設計不僅要求我具備紮實的技術基礎，還要求我具備嚴密的邏輯分析能力。這些經歷讓我更加成熟和自信，也為我未來的學習和工作打下了堅實的基礎。總的來說，這三次大型專案不僅鍛鍊了我的程式設計技巧，還加深了我對智慧家居電路工作原理及其實際應用的理解。我堅信，這些經歷和所學將為我未來的學習和工作提供巨大的幫助和啟發。