「人有悲歡離合，月有陰晴圓缺」，包括人在內，很多事物都具有多種狀態，而且在不同狀態下會具有不同的行為，這些狀態在特定條件下還將發生相互轉換。就像水，它可以凝固成冰，也可以受熱蒸發後變成水蒸汽，水可以流動，冰可以雕刻，蒸汽可以擴散。我們可以用uml狀態圖來描述h2o的三種狀態，如圖1所示：
圖1 h2o的三種狀態（未考慮臨界點）
在軟體系統中，有些物件也像水一樣具有多種狀態，這些狀態在某些情況下能夠相互轉換，而且物件在不同的狀態下也將具有不同的行為。為了更好地對這些具有多種狀態的物件進行設計，我們可以使用一種被稱之為狀態模式的設計模式，本章我們將學習用於描述物件狀態及其轉換的狀態模式。
1. 銀行系統中的賬戶類設計
sunny軟體公司欲為某銀行開發一套信用卡業務系統，銀行賬戶(account)是該系統的核心類之一，通過分析，sunny軟體公司開發人員發現在該系統中，賬戶存在三種狀態，且在不同狀態下賬戶存在不同的行為，具體說明如下：
(1) 如果賬戶中餘額大於等於0，則賬戶的狀態為正常狀態(normal state)，此時使用者既可以向該賬戶存款也可以從該賬戶取款；
(2) 如果賬戶中餘額小於0，並且大於-2000，則賬戶的狀態為透支狀態(overdraft state)，此時使用者既可以向該賬戶存款也可以從該賬戶取款，但需要按天計算利息；
(3) 如果賬戶中餘額等於-2000，那麼賬戶的狀態為受限狀態(restricted state)，此時使用者只能向該賬戶存款，不能再從中取款，同時也將按天計算利息；
(4) 根據餘額的不同，以上三種狀態可發生相互轉換。
sunny軟體公司開發人員對銀行賬戶類進行分析，繪製了如圖2所示uml狀態圖：
圖2 銀行賬戶狀態圖
在圖2中，normalstate表示正常狀態，overdraftstate表示透支狀態，restrictedstate表示受限狀態，在這三種狀態下賬戶物件擁有不同的行為，方法deposit()用於存款，withdraw()用於取款，computeinterest()用於計算利息，statecheck()用於在每一次執行存款和取款操作後根據餘額來判斷是否要進行狀態轉換並實現狀態轉換，相同的方法在不同的狀態中可能會有不同的實現。為了實現不同狀態下物件的各種行為以及物件狀態之間的相互轉換，sunny軟體公司開發人員設計了乙個較為龐大的賬戶類account，其中部分**如下所示：
class
account
//取款操作
public
void
withdraw
() else } //計算利息操作
public
void
computeinterest
() } //狀態檢查和轉換操作
public
void
statecheck
() else
if (balance > -2000 && balance < 0) else
if (balance == -2000) else
if (balance < -2000) } ......}
(1) 幾乎每個方法中都包含狀態判斷語句，以判斷在該狀態下是否具有該方法以及在特定狀態下該方法如何實現，導致**非常冗長，可維護性較差；
(2) 擁有乙個較為複雜的statecheck()方法，包含大量的if…else if…else…語句用於進行狀態轉換，**測試難度較大，且不易於維護；
(3) 系統擴充套件性較差，如果需要增加一種新的狀態，如凍結狀態（frozen state，在該狀態下既不允許存款也不允許取款），需要對原有**進行大量修改，擴充套件起來非常麻煩。
為了解決這些問題，我們可以使用狀態模式，在狀態模式中，我們將物件在每乙個狀態下的行為和狀態轉移語句封裝在乙個個狀態類中，通過這些狀態類來分散冗長的條件轉移語句，讓系統具有更好的靈活性和可擴充套件性，狀態模式可以在一定程度上解決上述問題。
「人有悲歡離合，月有陰晴圓缺」，包括人在內，很多事物都具有多種狀態，而且在不同狀態下會具有不同的行為，這些狀態在特定條件下還將發生相互轉換。就像水，它可以凝固成冰，也可以受熱蒸發後變成水蒸汽，水可以流動，冰可以雕刻，蒸汽可以擴散。我們可以用uml狀態圖來描述h2o的三種狀態，如圖1所示：
圖1 h2o的三種狀態（未考慮臨界點）
在軟體系統中，有些物件也像水一樣具有多種狀態，這些狀態在某些情況下能夠相互轉換，而且物件在不同的狀態下也將具有不同的行為。為了更好地對這些具有多種狀態的物件進行設計，我們可以使用一種被稱之為狀態模式的設計模式，本章我們將學習用於描述物件狀態及其轉換的狀態模式。
1. 銀行系統中的賬戶類設計
sunny軟體公司欲為某銀行開發一套信用卡業務系統，銀行賬戶(account)是該系統的核心類之一，通過分析，sunny軟體公司開發人員發現在該系統中，賬戶存在三種狀態，且在不同狀態下賬戶存在不同的行為，具體說明如下：
(1) 如果賬戶中餘額大於等於0，則賬戶的狀態為正常狀態(normal state)，此時使用者既可以向該賬戶存款也可以從該賬戶取款；
(2) 如果賬戶中餘額小於0，並且大於-2000，則賬戶的狀態為透支狀態(overdraft state)，此時使用者既可以向該賬戶存款也可以從該賬戶取款，但需要按天計算利息；
(3) 如果賬戶中餘額等於-2000，那麼賬戶的狀態為受限狀態(restricted state)，此時使用者只能向該賬戶存款，不能再從中取款，同時也將按天計算利息；
(4) 根據餘額的不同，以上三種狀態可發生相互轉換。
sunny軟體公司開發人員對銀行賬戶類進行分析，繪製了如圖2所示uml狀態圖：
圖2 銀行賬戶狀態圖
在圖2中，normalstate表示正常狀態，overdraftstate表示透支狀態，restrictedstate表示受限狀態，在這三種狀態下賬戶物件擁有不同的行為，方法deposit()用於存款，withdraw()用於取款，computeinterest()用於計算利息，statecheck()用於在每一次執行存款和取款操作後根據餘額來判斷是否要進行狀態轉換並實現狀態轉換，相同的方法在不同的狀態中可能會有不同的實現。為了實現不同狀態下物件的各種行為以及物件狀態之間的相互轉換，sunny軟體公司開發人員設計了乙個較為龐大的賬戶類account，其中部分**如下所示：
class
account
//取款操作
public
void
withdraw
() else } //計算利息操作
public
void
computeinterest
() } //狀態檢查和轉換操作
public
void
statecheck
() else
if (balance > -2000 && balance < 0) else
if (balance == -2000) else
if (balance < -2000) } ......}
(1) 幾乎每個方法中都包含狀態判斷語句，以判斷在該狀態下是否具有該方法以及在特定狀態下該方法如何實現，導致**非常冗長，可維護性較差；
(2) 擁有乙個較為複雜的statecheck()方法，包含大量的if…else if…else…語句用於進行狀態轉換，**測試難度較大，且不易於維護；
(3) 系統擴充套件性較差，如果需要增加一種新的狀態，如凍結狀態（frozen state，在該狀態下既不允許存款也不允許取款），需要對原有**進行大量修改，擴充套件起來非常麻煩。
為了解決這些問題，我們可以使用狀態模式，在狀態模式中，我們將物件在每乙個狀態下的行為和狀態轉移語句封裝在乙個個狀態類中，通過這些狀態類來分散冗長的條件轉移語句，讓系統具有更好的靈活性和可擴充套件性，狀態模式可以在一定程度上解決上述問題。
處理物件的多種狀態及其相互轉換 狀態模式（一）
人有悲歡離合，月有陰晴圓缺 包括人在內，很多事物都具有多種狀態，而且在不同狀態下會具有不同的行為，這些狀態在特定條件下還將發生相互轉換。就像水，它可以凝固成冰，也可以受熱蒸發後變成水蒸汽，水可以流動，冰可以雕刻，蒸汽可以擴散。我們可以用uml狀態圖來描述h2o的三種狀態，如圖1所示 圖1 h2o的三...
處理物件的多種狀態及其相互轉換 狀態模式（三）
sunny軟體公司開發人員使用狀態模式來解決賬戶狀態的轉換問題，客戶端只需要執行簡單的存款和取款操作，系統根據餘額將自動轉換到相應的狀態，其基本結構如圖4所示 圖4 銀行賬戶結構圖 在圖4中，account充當環境類角色，accountstate充當抽象狀態角色，normalstate overdr...
處理物件的多種狀態及其相互轉換 狀態模式（三）
sunny軟體公司開發人員使用狀態模式來解決賬戶狀態的轉換問題，客戶端只需要執行簡單的存款和取款操作，系統根據餘額將自動轉換到相應的狀態，其基本結構如圖4所示 圖4 銀行賬戶結構圖 在圖4中，account充當環境類角色，accountstate充當抽象狀態角色，normalstate overdr...