在狀態模式中，抽象狀態介面，定義統一的方法型別。子類實現該介面，補充具體的實現行為。乙個物件類，內部有狀態例項，並且有切換狀態的成員函式。當接收到外界的值（改變因素）時，在物件類的內部實現動態的狀態切換。
**塊
//狀態模式
public
class
test
//具體狀態實現a
class statea implements state
}//具體狀態實現b
class stateb implements state
}//擁有狀態的實現類
class man
public
void
setage(int age)else
}private state state;
}//測試
public
static
void
main(string args)
}
優點封裝了轉換規則。
列舉可能的狀態，在列舉狀態之前需要確定狀態種類。
將所有與某個狀態有關的行為放到乙個類中，並且可以方便地增加新的狀態，只需要改變物件狀態即可改變物件的行為
允許狀態轉換邏輯與狀態物件合成一體，而不是某乙個巨大的條件語句塊。
可以讓多個環境物件共享乙個狀態物件，從而減少系統中物件的個數。 缺點
狀態模式的使用必然會增加系統類和物件的個數。
狀態模式的結構與實現都較為複雜，如果使用不當將導致程式結構和**的混亂。
狀態模式對」開閉原則」的支援並不太好，對於可以切換狀態的狀態模式，增加新的狀態類需要修改那些負責狀態轉換的源**，否則無法切換到新增狀態，而且修改某個狀態類的行為也需修改對應類的源**。
試用場景
行為隨狀態改變而改變的場景。
條件、分支語句的代替者。
簡說原型模式
在原型模式下，我們在原型別下實現clone方法，通過呼叫本地辦法，實現原型別的複製。也就是說，新物件的建立，不在通過new的形式了，而是在底層通過位元組流的複製建立。當然，這其中有以下幾點需要特別注意 1 原型模式建立物件是不會呼叫構造方法的，這就跟單例模式有了衝突。2 原型模式建立物件的時候，涉及...
簡說責任鏈模式
在責任鏈模式中，抽象責任鏈定義了鏈式處理結構，具體的處理邏輯則由子類去實現。舉個例子 開發中，我們肯定會寫到邏輯判斷處理語句，如果需要進行邏輯判斷的情況很少，那麼幾個簡單的if else就足夠用了。但是，如果進行邏輯判斷的業務十分複雜，那麼單單乙個if判斷是很難處理的，即便是處理了，也會閒的臃腫不堪...
簡說設計模式 直譯器模式
直譯器這個名詞想必大家都不會陌生，比如編譯原理中，乙個算術表示式通過詞法分析器形成詞法單元，而後這些詞法單元再通過語法分析器構建語法分析樹，最終形成一顆抽象的語法分析樹。諸如此類的例子也有很多，比如編譯器 正規表示式等等。如果一種特定型別的問題發生的頻率足夠高，那麼可能就值得將該問題的各個例項表述為...