State設計模式理論篇
參考了王備戰老師的ppt,相當於是一次期末複習總結吧
⭐目標:目前的需求是我所製作的OJ專案在面臨程式碼提交結果以及執行結果時對於其中的各個狀態(如:透過!編譯失敗等等諸多狀態進行程式碼開發時,很容易程式碼一不小心就寫爛了,寫到連自己都無法看懂的地步,所以嘗試解決)
State適用性
一個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行為。
一個操作中含有龐大的多分支語句，且這些分支依賴於該物件的狀態。這個狀態通常用一個或多個列舉量表示。
State模式將每個條件分支放入一個獨立的表示狀態及其行為的類中。
目前判定可能可行,我們可以將對應判題結果歸於對應的狀態,而例如說編譯失敗狀態,我們就不用再填裝第一個沒有透過的測試用例
不過不滿足的地方也有,我們的需求主要是根據對應程式碼沙箱返回結果來賦值對應的程式碼提交結果
效果
它將與特定狀態行為相關的行為區域性化，並且將不同狀態的行為分割開來。
這一句其實沒有給我較大的啟發,但是我卻想到了另外的一個思路,不妨我也照著對應的金庫保安系統抽象出一個提交結果管理員(類),由他們來進行對應的操作,例如說接收到對應的程式碼沙箱執行結果後,進行對應的操作,根據返回結果的狀態修改其自身,同時讓其能夠擁有對應的狀態該操作的能力
UML
State Pattern的參與者：
State：不同狀態下所有方法的集合
ConcreteState:具體的不同的狀態下的行為，實現了State
Context：（上下文）Context和SafeFrame，Context介面負責規定API，而SafeFrame則是 擁有 具有ConcreteState們的參與者。
更具體的UML
環境類與抽象狀態類的作用：
•環境類實際上就是擁有狀態的物件，環境類有時候可以充當狀態管理器(State Manager)的角色，可以在環境類中對狀態進行切換操作，它的例項定義了當前的狀態。
•抽象狀態類可以是抽象類，也可以是介面，不同狀態類就是繼承這個父類的不同子類。狀態類的產生是由於環境類存在多個狀態，同時還滿足兩個條件：1、這些狀態經常需要切換；2、在不同的狀態下物件的行為不同。因此可以將不同物件下的行為單獨提取出來封裝在具體的狀態類中，使得環境類物件在其內部狀態改變時可以改變它的行為，物件看起來似乎修改了它的類，而實際上是由於切換到不同的具體狀態類實現的。由於環境類可以設定為任一具體狀態類，因此它針對抽象狀態類進行程式設計，在程式執行時可以將任一具體狀態類的物件設定到環境類中，從而使得環境類可以改變內部狀態並且改變行為。
啟發
Divide and Conquer:分割控制，分體分解。State Pattern利用類表示系統狀態，依據狀態分解了複雜的系統。OO的核心就是程式碼的責任分解：單一職責原則。因為任何改動和變化都是致命的，如同刻板印刷一下。
有狀態才會有處理，因狀態而異的處理。
狀態模式允許物件（CONTEXT）在內部狀態改變時改變它的行為，物件看起來好像修改了它的類。實際上，我們是在使用組合透過引用不同的狀態物件來造成類改變的假象。
Context的客戶對於狀態物件瞭解不多，甚至渾然不知。
總結
綜合看來是可以的,我們甚至可以結合一下對應的工廠方法來進行生產對應的JudgeRes
2024/6/4號更新下章(嘗試落地)