1.概述
在軟件開發過程中，應用程序可能會根據不同的情況作出不同的處理。最直接的解決方案是將這些所有可能發生的情況全都考慮到。然后使用if... ellse語句來做狀態判斷來進行不同情況的處理。但是對復雜狀態的判斷就顯得“力不從心了”。隨著增加新的狀態或者修改一個狀體（if else(或switch case)語句的增多或者修改）可能會引起很大的修改，而程序的可讀性，擴展性也會變得很弱。維護也會很麻煩。那么我就考慮只修改自身狀態的模式。
例子1：按鈕來控制一個電梯的狀態，一個電梯開們，關門，停，運行。每一種狀態改變，都有可能要根據其他狀態來更新處理。例如，開門狀體，你不能在運行的時候開門，而是在電梯定下后才能開門。
例子2：我們給一部手機打電話，就可能出現這幾種情況：用戶開機，用戶關機，用戶欠費停機，用戶消戶等。 所以當我們撥打這個號碼的時候：系統就要判斷，該用戶是否在開機且不忙狀態，又或者是關機，欠費等狀態。但不管是那種狀態我們都應給出對應的處理操作。
2.問題
對象如何在每一種狀態下表現出不同的行為？
3.解決方案
狀態模式：允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它的類。
在很多情況下，一個對象的行為取決于一個或多個動態變化的屬性，這樣的屬性叫做狀態，這樣的對象叫做有狀態的(stateful)對象，這樣的對象狀態是從事先定義好的一系列值中取出的。當一個這樣的對象與外部事件產生互動時，其內部狀態就會改變，從而使得系統的行為也隨之發生變化。
4.示例
先給出這個例子的類結構圖。
上面的類結構圖并不復雜，首先是抽象出一個狀態的父類，通過工作類對時間點的設置來切換不同的狀態。
邏輯結構并不復雜，還是給出簡易的代碼，大家可以慢慢體會一下。
注意：本文所有代碼均在ARC環境下編譯通過。
Work類接口
@class State;
@interface Work :NSObject{
State *current;
}
@property double Hour;
@property BOOL TaskFinished;
-(void)SetState:(State*)s;
-(void)WriteProgram;
@end
@implementation Work
@synthesize Hour =_Hour;
@synthesize TaskFinished =_TaskFinished;
-(id)init{
if (self == [superinit]) {
current= [[ForenoonState alloc]init];
}
return self;
}
-(void)SetState:(State *)s{
current = s;
}
-(void)WriteProgram{
[current WriteProgram:self];
}
@end
@class Work;
@interface State:NSObject
-(void)WriteProgram:(Work*)w;
@end
@implementation State
-(void)WriteProgram:(Work *)w{
NSLog(@"當前時間:%f點下班回家了",[w Hour]);
}
@end
@interface ForenoonState :State
@end
@implementation ForenoonState
-(void)WriteProgram:(Work *)w{
if ([w Hour] < 12) {
NSLog(@"當前時間:%f點上午工作,精神百倍", [w Hour]);
}
else {
[w SetState:[NoonState new]];
[w WriteProgram];
}
}
@end
@interface NoonState:State
@end
@implementation NoonState
-(void)WriteProgram:(Work *)w{
if([w Hour] <13)
NSLog(@"當前時間:%f點餓了,午飯;犯困,午休",[w Hour]);
else {
[w SetState:[[AfternoonState alloc]init]];
[w WriteProgram];
}
}
@end
@interface AfternoonState :State
@end
@implementation AfternoonState
-(void)WriteProgram:(Work *)w{
if ([w Hour] <17) {
NSLog(@"當前時間:%f點下午狀態還不錯,繼續努力", [w Hour]);
}
else {
[w SetState:[[EveningState alloc]init]];
[w WriteProgram];
}
}
@end
@interface EveningState:State
@end
@implementation EveningState
-(void)WriteProgram:(Work *)w{
if ([w TaskFinished]) {
[w SetState:[[RestState alloc]init]];
[w WriteProgram];
}
else {
if([w Hour] <21)
NSLog(@"當前時間:%f點加班哦,疲憊之極", [w Hour]);
else {
[w SetState:[[SleepingState alloc]init]];
[w WriteProgram];
}
}
}
@end
@interface SleepingState :State
@end
@implementation SleepingState
-(void)WriteProgram:(Work *)w{
NSLog(@"當前時間:%f點不行了,睡著了", [w Hour]);
}
@end
@implementation RestState
-(void)WriteProgram:(Work *)w{
NSLog(@"當前時間:%f點下班回家了", [w Hour]);
}
@end
int main (int argc,const char *argv[])
{
@autoreleasepool{
Work *emergencyProjects = [[Work alloc]init];
[emergencyProjects setHour:9];
[emergencyProjects WriteProgram];
[emergencyProjects setHour:10];
[emergencyProjects WriteProgram];
[emergencyProjects setHour:12];
[emergencyProjects WriteProgram];
[emergencyProjects setHour:13];
[emergencyProjects WriteProgram];
[emergencyProjects setHour:14];
[emergencyProjects WriteProgram];
[emergencyProjects setHour:17];
[emergencyProjects WriteProgram];
[emergencyProjects setTaskFinished:NO];
[emergencyProjects setHour:19];
[emergencyProjects WriteProgram];
[emergencyProjects setHour:22];
[emergencyProjects WriteProgram];
}
return 0;
}
通過這個例子，可以看到，狀態模式通過把各種狀態轉移邏輯分布到State的子類之間，來減少相互間的依賴。當一個對象的行為取決于它的狀態，并且它必須在運行時刻根據狀態改變它的行為時，就可以考慮使用狀態模式了。
5.適用性
在下面的兩種情況下均可使用State模式:
1) • 一個對象的行為取決于它的狀態, 并且它必須在運行時刻根據狀態改變它的行為。
2) • 代碼中包含大量與對象狀態有關的條件語句:一個操作中含有龐大的多分支的條件（if else(或switch case)語句，且這些分支依賴于該對象的狀態。這個狀態通常用一個或多個枚舉常量表示。通常 , 有多個操作包含這一相同的條件結構。 State模式將每一個條件分支放入一個獨立的類中。這使得你可以根據對象自身的情況將對象的狀態作為一個對象，這一對象可以不依賴于其他對象而獨立變化。
6.結構
7.模式的組成
環境類（Context）: 定義客戶感興趣的接口。維護一個ConcreteState子類的實例，這個實例定義當前狀態。
抽象狀態類（State）: 定義一個接口以封裝與Context的一個特定狀態相關的行為。
具體狀態類（ConcreteState）: 每一子類實現一個與Context的一個狀態相關的行為。
8.效果
State模式有下面一些效果:
狀態模式的優點：
1 ) 它將與特定狀態相關的行為局部化，并且將不同狀態的行為分割開來: State模式將所有與一個特定的狀態相關的行為都放入一個對象中。因為所有與狀態相關的代碼都存在于某一個State子類中, 所以通過定義新的子類可以很容易的增加新的狀態和轉換。另一個方法是使用數據值定義內部狀態并且讓 Context操作來顯式地檢查這些數據。但這樣將會使整個Context的實現中遍布看起來很相似的條件if else語句或switch case語句。增加一個新的狀態可能需要改變若干個操作, 這就使得維護變得復雜了。State模式避免了這個問題, 但可能會引入另一個問題, 因為該模式將不同狀態的行為分布在多個State子類中。這就增加了子類的數目，相對于單個類的實現來說不夠緊湊。但是如果有許多狀態時這樣的分布實際上更好一些, 否則需要使用巨大的條件語句。正如很長的過程一樣，巨大的條件語句是不受歡迎的。它們形成一大整塊并且使得代碼不夠清晰，這又使得它們難以修改和擴展。 State模式提供了一個更好的方法來組織與特定狀態相關的代碼。決定狀態轉移的邏輯不在單塊的 i f或s w i t c h語句中, 而是分布在State子類之間。將每一個狀態轉換和動作封裝到一個類中，就把著眼點從執行狀態提高到整個對象的狀態。這將使代碼結構化并使其意圖更加清晰。
2) 它使得狀態轉換顯式化: 當一個對象僅以內部數據值來定義當前狀態時 , 其狀態僅表現為對一些變量的賦值，這不夠明確。為不同的狀態引入獨立的對象使得轉換變得更加明確。而且, State對象可保證Context不會發生內部狀態不一致的情況，因為從 Context的角度看，狀態轉換是原子的―只需重新綁定一個變量(即Context的State對象變量)，而無需為多個變量賦值
3) State對象可被共享 如果State對象沒有實例變量―即它們表示的狀態完全以它們的類型來編碼―那么各Context對象可以共享一個State對象。當狀態以這種方式被共享時, 它們必然是沒有內部狀態, 只有行為的輕量級對象。
狀態模式的缺點:
1) 狀態模式的使用必然會增加系統類和對象的個數。
2) 狀態模式的結構與實現都較為復雜，如果使用不當將導致程序結構和代碼的混亂。
新聞熱點
疑難解答
