在寫程式的時候，我們經常會碰到這樣的情境：把一堆演算法塞到同一段代碼中，然後使用if-else或switch-case條件陳述式來決定要使用哪個演算法？這些演算法可能是一堆相似的類函數或方法，用以解決相關的問題。比如，一個驗證輸入資料的常式，資料本身可以是任何資料類型（如NSString、CGFloat等），每種資料類型需要不同的驗證演算法。如果能把每個演算法封裝成一個對象，那麼就能消除根據資料類型決定使用什麼演算法的一堆if-else或switch-case語句。
我們把相關演算法分離為不同的類，稱為策略模式。策略模式：定義一系列演算法，把它們一個個封裝起來，並且使它們可相互替換。本模式使得演算法可獨立於使用它的用戶端而變化。
在以下情形下，我們應該考慮使用原則模式。
@：一個類在其操作中，使用多個條件陳述式來定義許多行為，我們可以把相關的條件分支移到它們自己的策略類中。
@：需要演算法的各種變體。
@：需要避免把複雜的、與演算法相關的資料結構暴漏給用戶端。
我們用一個簡單的例子來說明以下，策略模式是怎麼使用的。假設有兩個UITextField，一個UITextField只能輸入字母，另一個UITextField只能輸入數字，為了確保輸入的有效性，我們需要在使用者結束文字框的編輯時做下驗證。我們把資料驗證放在代理方法textFieldDidEndEdting中。
如果不使用原則模式，我們的代碼會寫成這樣：
複製代碼 代碼如下:
- (void)textFieldDidEndEditing:(UITextField *)textField {
if (textField == self.numberTF) {
// 驗證其值只包含數字
}else if (textField == self.alphaTF) {
// 驗證其值只包含字母
}
}
要是有更多不同類型的文字框，條件陳述式還會繼續下去。如果能去掉這些條件陳述式，代碼會更容易管理，將來對代碼的維護也會容易許多。
現在的目標是把這些驗證檢查提到各種策略類中，這樣他們就能在代理方法和其他方法之中重用。每個驗證都從文字框取出輸入值，然後根據所H需的策略進行驗證，最後返回一個BOOL值。如果返回失敗，還會返回一個NSError執行個體。返回的NSError可以解釋失敗的原因。
我們設計一個抽象基類InputValidator，裡面有一個validateInput:input error:error方法。分別有兩個子類NumberInputValidator、AlphaInputValidator。具體的代碼如下所示：
InputValidator.h中抽象InputValidator的類聲明
複製代碼 代碼如下:
static NSString *const InputValidationErrorDomain = @"InputValidationErrorDomain";
@interface InputValidator : NSObject
/**
* 實際驗證策略的存根方法
*/
- (BOOL)validateInput:(UITextField *)input error:(NSError *__autoreleasing *)error;
@end
這個方法還有一個NSError指標的引用，當有錯誤發生時（即驗證失敗），方法會構造一個NSError執行個體，並賦值給這個指標，這樣使用驗證的地方就能做詳細的錯誤處理。
InputValidator.m中抽象InputValidator的預設實現
#import "InputValidator.h"
複製代碼 代碼如下:
@implementation InputValidator
- (BOOL)validateInput:(UITextField *)input error:(NSError *__autoreleasing *)error {
if (error) {
*error = nil;
}
return NO;
}
@end
我們已經定義了輸入驗證器的行為，然後我們要編寫真正的輸入驗證器了，先來寫數值型的，如下：
NumberInputValidator.h中NumberInputValidator的類定義
複製代碼 代碼如下:
#import "InputValidator.h"
@interface NumberInputValidator : InputValidator
/**
* 這裡重新聲明了這個方法，以強調這個子類實現或重載了什麼，這不是必須的，但是是個好習慣。
*/
- (BOOL)validateInput:(UITextField *)input error:(NSError *__autoreleasing *)error;
@end
NumberInputValidator.m中NumberInputValidator的實現
複製代碼 代碼如下:
#import "NumberInputValidator.h"
@implementation NumberInputValidator
- (BOOL)validateInput:(UITextField *)input error:(NSError *__autoreleasing *)error {
NSError *regError = nil;
NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"^[0-9]*$" options:NSRegularExpressionAnchorsMatchLines error:®Error];
NSUInteger numberOfMatches = [regex numberOfMatchesInString:input.text options:NSMatchingAnchored range:NSMakeRange(0, input.text.length)];
// 如果沒有匹配，就會錯誤和NO.
if (numberOfMatches == 0) {
if (error != nil) {
// 先判斷error對象是存在的
NSString *description = NSLocalizedString(@"驗證失敗", @"");
NSString *reason = NSLocalizedString(@"輸入僅能包含數字", @"");
NSArray *objArray = [NSArray arrayWithObjects:description, reason, nil];
NSArray *keyArray = [NSArray arrayWithObjects:NSLocalizedDescriptionKey, NSLocalizedFailureReasonErrorKey, nil];
NSDictionary *userInfo = [NSDictionary dictionaryWithObjects:objArray forKeys:keyArray];
//錯誤被關聯到定製的錯誤碼1001和在InputValidator的標頭檔中。
*error = [NSError errorWithDomain:InputValidationErrorDomain code:1001 userInfo:userInfo];
}
return NO;
}
return YES;
}
@end
現在，我們來編寫字母驗證的實現，代碼如下：
AlphaInputValidator.h中AlphaInputValidator的類定義
複製代碼 代碼如下:
#import "InputValidator.h"
@interface AlphaInputValidator : InputValidator
- (BOOL)validateInput:(UITextField *)input error:(NSError *__autoreleasing *)error;
@end
AlphaInputValidator.m中AlphaInputValidator的實現:
#import "AlphaInputValidator.h"
複製代碼 代碼如下:
@implementation AlphaInputValidator
- (BOOL)validateInput:(UITextField *)input error:(NSError *__autoreleasing *)error {
NSError *regError = nil;
NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"^[a-zA-Z]*$" options:NSRegularExpressionAnchorsMatchLines error:®Error];
NSUInteger numberOfMatches = [regex numberOfMatchesInString:input.text options:NSMatchingAnchored range:NSMakeRange(0, input.text.length)];
// 如果沒有匹配，就會錯誤和NO.
if (numberOfMatches == 0) {
if (error != nil) {
// 先判斷error對象是存在的
NSString *description = NSLocalizedString(@"驗證失敗", @"");
NSString *reason = NSLocalizedString(@"輸入僅能包字母", @"");
NSArray *objArray = [NSArray arrayWithObjects:description, reason, nil];
NSArray *keyArray = [NSArray arrayWithObjects:NSLocalizedDescriptionKey, NSLocalizedFailureReasonErrorKey, nil];
NSDictionary *userInfo = [NSDictionary dictionaryWithObjects:objArray forKeys:keyArray];
*error = [NSError errorWithDomain:InputValidationErrorDomain code:1002 userInfo:userInfo]; //錯誤被關聯到定製的錯誤碼1002和在InputValidator的標頭檔中。
}
return NO;
}
return YES;
}
@end
AlphaInputValidator也是實現了validateInput方法的InputValidator類型。它的代碼結構和演算法跟NumberInputValidator相似，只是使用了不同的Regex，不同錯誤碼和訊息。可以看到兩個版本的代碼有很多重複。兩個演算法結構相同，我們可以把這個結構，我們可以把這個結構重構成抽象父類的模板方法（將在下一篇部落格中，來進行實現）。
至此，我們已經寫好了輸入驗證器，可以在用戶端來使用了，但是UITextField不認識它們，所以我們需要自己的UITextField版本。我們要建立UITextField的子類，其中有一個InputValidator的引用，以及一個方法validate。代碼如下：
CustomTextField.h中CustomTextField的類聲明
複製代碼 代碼如下:
#import <UIKit/UIKit.h>
#import "InputValidator.h"
@interface CustomTextField : UITextField
@property (nonatomic, strong) InputValidator *inputValidator; //用一個屬性保持對InputValidator的引用。
- (BOOL)validate;
@end
CustomTextField有一個屬性保持著對InputValidator的引用。當調用它的validate方法時，它會使用這個InputValidator引用，開始進行實際的驗證過程。
CustomTextField.m中CustomTextField的實現
複製代碼 代碼如下:
#import "CustomTextField.h"
@implementation CustomTextField
- (BOOL)validate {
NSError *error = nil;
BOOL validationResult = [_inputValidator validateInput:self error:&error];
if (!validationResult) {
// 通過這個例子也讓自己明白了，NSError的具體用法。
UIAlertView *alertView = [[UIAlertView alloc]initWithTitle:[error localizedDescription] message:[error localizedFailureReason] delegate:nil cancelButtonTitle:@"確定" otherButtonTitles:nil, nil];
[alertView show];
}
return validationResult;
}
@end
validate方法向inputValidator引用發送了[_inputValidator validateInput:self error:&error]訊息。CustomTextField無需知道使用的是什麼類型的InputValidator以及演算法的任何細節，這就是策略模式的好處。對於用戶端使用來說，只需要調用validate方法就可以了。因此在將來如果添加了新的InputValidator,用戶端不需要做任何的改動的。
下面，我們看下用戶端是怎麼使用的，代碼如下。
複製代碼 代碼如下:
#import "ViewController.h"
#import "CustomTextField.h"
#import "InputValidator.h"
#import "NumberInputValidator.h"
#import "AlphaInputValidator.h"
@interface ViewController () <UITextFieldDelegate>
@property (weak, nonatomic) IBOutlet CustomTextField *numberTF;
@property (weak, nonatomic) IBOutlet CustomTextField *alphaTF;
@end
@implementation ViewController
複製代碼 代碼如下:
- (void)viewDidLoad {
[super viewDidLoad];
InputValidator *numberValidator = [[NumberInputValidator alloc] init];
InputValidator *alphaValidator = [[AlphaInputValidator alloc] init];
_numberTF.inputValidator = numberValidator;
_alphaTF.inputValidator = alphaValidator;
}
- (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}
#pragma mark - UITextFieldDelegate
- (void)textFieldDidEndEditing:(UITextField *)textField {
if ([textField isKindOfClass:[CustomTextField class]]) {
[(CustomTextField *)textField validate];
}
}
@end
可以看出，我們不需要那些條件陳述式了，相反，我們使用一條簡潔得多的語句，實現同樣的資料驗證。除了上面多了一條確保textField對象的類型是CustomField的額外檢查之外，不應再有任何複雜的東西。
Strategy模式有下面的一些優點：
1) 相關演算法系列 Strategy類層次為Context定義了一系列的可供重用的演算法或行為。 繼承有助於析取出這些演算法中的公用功能。
2) 提供了可以替換繼承關係的辦法： 繼承提供了另一種支援多種演算法或行為的方法。你可以直接產生一個Context類的子類，從而給它以不同的行為。但這會將行為硬行編製到 Context中，而將演算法的實現與Context的實現混合起來,從而使Context難以理解、難以維護和難以擴充，而且還不能動態地改變演算法。最後你得到一堆相關的類 , 它們之間的唯一差別是它們所使用的演算法或行為。 將演算法封裝在獨立的Strategy類中使得你可以獨立於其Context改變它，使它易於切換、易於理解、易於擴充。
3) 消除了一些if else條件陳述式 ：Strategy模式提供了用條件陳述式選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 ,很難避免使用條件陳述式來選擇合適的行為。將行為封裝在一個個獨立的Strategy類中消除了這些條件陳述式。含有許多條件陳述式的代碼通常意味著需要使用Strategy模式。
4) 實現的選擇 Strategy模式可以提供相同行為的不同實現。客戶可以根據不同時間 /空間權衡取捨要求從不同策略中進行選擇。
Strategy模式缺點:
1)用戶端必須知道所有的策略類，並自行決定使用哪一個策略類: 本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。
2 ) Strategy和Context之間的通訊開銷 ：無論各個ConcreteStrategy實現的演算法是簡單還是複雜, 它們都共用Strategy定義的介面。因此很可能某些 ConcreteStrategy不會都用到所有通過這個介面傳遞給它們的資訊；簡單的 ConcreteStrategy可能不使用其中的任何資訊！這就意味著有時Context會建立和初始化一些永遠不會用到的參數。如果存在這樣問題 , 那麼將需要在Strategy和Context之間更進行緊密的耦合。
3 )策略模式將造成產生很多策略類：可以通過使用享元模式在一定程度上減少對象的數量。 增加了對象的數目 Strategy增加了一個應用中的對象的數目。有時你可以將 Strategy實現為可供各Context共用的無狀態的對象來減少這一開銷。任何其餘的狀態都由 Context維護。Context在每一次對Strategy對象的請求中都將這個狀態傳遞過去。共用的 Strategy不應在各次調用之間維護狀態。
