戦略（Carlo Chung著「Pro Objective-C Design Patterns for iOS」の英語の章「Strategy」から翻訳）

前回、多くの異なるアルゴリズムでコードのブロックを開始し、if-else / switch-case条件のスパゲッティを使用して、使用するコードを決定したことを覚えていますか。 アルゴリズムは、同様の問題を解決する同様のクラスの関数/メソッドのセットです。 たとえば、入力をチェックする手順があります。 データ自体は任意のタイプ（ CGFloat 、 NSString 、 NSIntegerなど）にすることができます。 データ型ごとに異なる検証アルゴリズムが必要です。 各アルゴリズムをオブジェクトとしてカプセル化できる場合、if-else / switch-caseステートメントのグループを使用してデータをチェックし、必要なアルゴリズムを決定することはできません。

オブジェクト指向プログラミングでは、関連するアルゴリズムをさまざまなクラスの戦略に区別できます。 このような場合に使用される設計パターンは、戦略と呼ばれます。 この章では、Strategyパターンの概念と主要な機能について説明します。 この章の後半で、 UITextFieldテキストフィールドUITextField入力を検証するための戦略として、データを検証するためのいくつかのクラスを設計および実装します。

戦略パターンとは何ですか？

このパターンの重要な役割の1つは、サポートされるすべてのアルゴリズムの共通インターフェースを宣言するストラテジークラスによって果たされます。 戦略インターフェースを使用してアルゴリズムを実装する戦略の特定のクラスもあります。 コンテキストオブジェクトは、特定の戦略オブジェクトのインスタンスを使用して構成されます。 コンテキストオブジェクトは、戦略インターフェイスを使用して、特定の戦略クラスで定義されたアルゴリズムを呼び出します。 これらの関係は、図19–1のクラス図に示されています。


図19-1。 クラス構造パターン戦略

ConcreteStrategyクラス（A、B、およびC）の形式の関連アルゴリズムのグループまたは階層は、共通のalgorithmInterface共有するため、 Contextは同じインターフェースを使用して異なるバージョンのアルゴリズムにアクセスできます。

ご注意 戦略パターン ：アルゴリズムのファミリーを定義し、それらのそれぞれをカプセル化し、それらを交換可能にします。 この戦略により、アルゴリズムを使用する顧客とは無関係にアルゴリズムを変更できます。

GoFのデザインパターン（Addison-Wesley、1994）で与えられた初期定義。

Contextインスタンスは、実行時にさまざまなConcreteStrategyオブジェクトを使用して構成できます。 変更は内部から発生するため、これはContextオブジェクトの「内部」の変更と見なすことができます。 対照的に、デコレーター（第16章、デコレーターパターンと以前の記事を参照）は、変更が外部からドッキングされるため、オブジェクトの「スキン」を変更します。 相違点の詳細については、第16章（前の記事）の「内部」の変更と比較したオブジェクトの「スキン」の変更のセクションを参照してください。

Model-View-Controllerの戦略パターン

Model-View-Controllerパターンでは、コントローラーはモデルに含まれるデータをいつどのように表示するかを決定します。 ビュー自体は何かを表示する方法を知っていますが、コントローラーがそれを示すまでそれを知りません。 別のコントローラーを使用し、同じフォームを使用する場合、出力データの形式は同じかもしれませんが、新しいコントローラーからの他の結論に従ってデータ型が異なる場合があります。 この場合のコントローラーは、いわば、ビューオブジェクトの戦略です。 前の章で述べたように、コントローラーとビューの関係は戦略パターンに基づいています。

戦略パターンの使用はいつ適切ですか？

このパターンの使用は、次の場合に推奨されます。

• クラスロジックは、多くの条件ステートメントを使用して、目的の動作を選択します。 条件コードを別の戦略クラスに移動できます。
• 異なるバージョンのアルゴリズムが必要です。
• 複雑で狭い特定のデータ構造を（顧客に）公開したくないでしょう。

UITextFieldクラスを例として使用したデータ検証戦略の使用

アプリケーションでの戦略パターンの実装の簡単な例を作成しましょう。 ユーザー入力を受け付けるUITextFieldオブジェクトがアプリケーションに必要だとします。 後でアプリケーションで入力結果を使用します。 文字（a〜zまたはA〜Z）のみを受け入れるテキスト入力フィールドがあり、数値データ（0〜9）のみを受け入れるフィールドもあります。 フィールドへの入力が正しいことを確認するために、各フィールドには、ユーザーが編集を終了した後に起動する、何らかの種類のオンサイトデータ検証手順が必要です。

デリゲートオブジェクトのメソッドUITextField 、 textFieldDidEndEditing:必要なデータ検証を配置できtextFieldDidEndEditing: UITextFieldインスタンスは、フォーカスを失うたびにこのメソッドを呼び出します。 この方法では、数字のみがデジタルフィールドに入力され、文字のみがアルファベットフィールドに入力されるようにすることができます。 このメソッドは、入力フィールドの現在のオブジェクトへのリンクで（ textFieldパラメーターの形式で）受け入れますが、これは2つのオブジェクトのどちらですか？

Tragiaパターンがなければ、リスト19–1に示すようなコードになります。

リスト19–1。 デリゲートメソッドtextFieldDidEndEditingの典型的なUITextFieldコンテンツ検証スクリプト

 - (void)textFieldDidEndEditing:(UITextField *)textField { if (textField == numericTextField) { //  [textField text]  , //    } else if (textField == alphaTextField) { //  [textField text]  , //      } } 

もちろん、異なるデータの入力フィールドが多い場合、条件ステートメントが増える可能性があります。 これらのすべての条件式を取り除けば、コードをより管理しやすくすることができます。これにより、コードのサポートにより将来の生活が大幅に簡素化されます。

ヒント：コードに多くの条件ステートメントがある場合、これはそれらをリファクタリングし、ストラテジーの個別のオブジェクトに分離する必要があることを意味する場合があります。

ここでの目標は、この検証コードを取得して、さまざまなクラスの戦略に分散させ、デリゲートやその他のメソッドで再利用できるようにすることです。 各クラスは入力フィールドから行を取得し、目的の戦略に基づいてチェックし、チェックが失敗した場合は最終的にBOOL型の値とNSErrorインスタンスを返します。 返されたNSErrorオブジェクトは、検証が成功しなかった理由を判断するのに役立ちます。 デジタル入力と文字入力の両方の検証は互いに関連しているため（同じタイプの入力と出力を持っています）、1つのインターフェースと組み合わせることができます。 クラスのセットを図19–2のクラス図に示します。


図19–2。 クラス図は、CustomTextFieldとそれに関連する戦略の関係を示しています。

このインターフェイスをプロトコルとしてではなく、抽象基本クラスとして宣言します。 この場合、抽象基本クラスの方が便利です。これは、戦略のすべての具体的なクラスに共通する動作をリファクタリングする方が簡単だからです。 抽象基本クラスはリスト19–2のようになります。

リスト19–2。 InputValidator.hでInputValidatorクラスを宣言する

 @interface InputValidator : NSObject { } //      - (BOOL) validateInput:(UITextField *)input error:(NSError **) error; @end 

validateInput: error:メソッドは、入力パラメーターとしてUITextFieldへの参照を受け入れるため、入力フィールドのすべてをチェックし、チェックの結果としてBOOL値を返します。 このメソッドは、 NSErrorへのポインターへの参照も受け入れます。 何らかのエラーが発生した場合（つまり、メソッドが入力の正当性を検証できなかった場合）、メソッドはNSErrorインスタンスを作成し、ポインターに割り当てます。したがって、検証クラスが使用されるどのようなコンテキストでも、このオブジェクトからエラーに関するより詳細な情報を取得できます。

リスト19-3で示されるように、このメソッドのデフォルト実装はエラーポインタをnil設定し、 NOを返します。

リスト19-3。 InputValidator.mのInputValidatorクラスのデフォルト実装

 #import "InputValidator.h" @implementation InputValidator //      - (BOOL) validateInput:(UITextField *)input error:(NSError **) error { if (error) { *error = nil; } return NO; } @end 

NSStringを入力パラメーターとして使用しなかったのはなぜですか？ この場合、ストラテジーオブジェクト内のアクションは一方的です。 つまり、バリデーターは元の値を変更せずに単純にチェックを実行し、結果を返すだけです。 タイプUITextField入力パラメーターを使用して、2つのアプローチを組み合わせることができます。 スキャンオブジェクトは、テキストフィールドの初期値を変更することができます（たとえば、間違った文字を削除することによって）、または値を変更せずに表示するだけです。

別の質問は、なぜチェックが失敗した場合にNSExceptionスローしないのですか？ これは、独自の例外をスローして、Cocoa Touchフレームワークのtry-catchブロックでキャッチすることは非常にリソースを消費する操作であり、推奨されないためです（ただし、try-catchシステム例外はまったく別の問題です）。 Cocoa Touch開発者ガイドで推奨されているように、 NSErrorオブジェクトを返す方が比較的安価です。 Cocoa Touchフレームワークのドキュメントを見ると、何らかの異常な状況が発生したときにNSErrorインスタンスを返すAPIがたくさんあることに気付くでしょう。 一般的な例は、 NSFileManagerメソッドの1つ、 (BOOL)moveItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)errorです。 NSFileManagerがファイルをある場所から別の場所に移動しようとしたときにエラーが発生した場合、問題を説明する新しいNSErrorインスタンスが作成されます。 呼び出しメソッドは、返されたNSErrorオブジェクトに含まれる情報を使用して、エラーをさらに処理できます。 したがって、このメソッドのNSErrorオブジェクトの目標は、作業拒否に関する情報を提供することです。

これで、適切な入力検証クラスの動作方法を定義しました。 これで、実際のレビュー担当者の作成を開始できます。 リスト19-4で示されるように、最初に数字を入力するための1つを作成しましょう。

リスト19-4。 NumericInputValidator.hでNumericInputValidatorクラスを宣言する

 #import "InputValidator.h" @interface NumericInputValidator : InputValidator { } //  ,  ,     // ,   0-9 - (BOOL) validateInput:(UITextField *)input error:(NSError **) error; @end 

NumericInputValidatorは、抽象基本クラスInputValidatorを継承し、そのvalidateInput: error:メソッドをオーバーライドします。 このサブクラスがメソッドを実装または再定義することを強調するために、メソッドを再度宣言します。 これは必須ではありませんが、良い習慣です。

メソッドの実装をリスト19–5に示します。

リスト19-5。 NumericInputValidator.mのNumericInputValidatorクラスの実装

 #import "NumericInputValidator.h" @implementation NumericInputValidator - (BOOL) validateInput:(UITextField *)input error:(NSError**) 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) { NSString *description = NSLocalizedString(@"Input Validation Failed", @""); NSString *reason = NSLocalizedString(@"The input can contain only numerical values", @""); 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:1001 userInfo:userInfo]; } return NO; } return YES; } @end 

validateInput:error:メソッドの実装は、主に2つの側面に焦点を当てています。

1. 入力フィールドの数値データと、以前に作成されたNSRegularExpressionオブジェクトとの一致数をチェックします。 使用した正規表現は「^ [0–9] * $」です。 これは、行全体の先頭（「^」で示される）および末尾（「$」で示される）から、数字のみ（「[0–9]で示される）を含むセットの0個以上の文字（「*」で示される）が必要であることを意味します"）。
2. 一致するものがまったくない場合、「入力には数値のみを含めることができます」というメッセージを含む新しいNSErrorオブジェクトを作成し、 NSErrorへの入力ポインターに割り当てます。 次に、操作の成功または失敗を示すBOOL型の値を最終的に返します。 このエラーは、以下に示すように、 InputValidatorクラスのヘッダーファイルで定義されている特別なコード1001およびエラードメインの特別な値に関連付けられています。
   

    static NSString * const InputValidationErrorDomain = @"InputValidationErrorDomain"; 

NumericInputValidatorと呼ばれる、入力内の文字のみをチェックするNumericInputValidatorクラスの兄弟には、入力フィールドの内容をチェックするための同様のアルゴリズムが含まれています。 AlphaInputValidatorは、 AlphaInputValidatorと同じメソッドをオーバーライドします。 リスト19-6に示すように、明らかにこのアルゴリズムは入力文字列に文字のみが含まれていることを検証します。

リスト19-6。 AlphaInputValidator.mのAlphaInputValidatorクラスの実装

 #import "AlphaInputValidator.h" @implementation AlphaInputValidator - (BOOL) validateInput:(UITextField *)input error:(NSError**) 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) { NSString *description = NSLocalizedString(@"Input Validation Failed", @""); NSString *reason = NSLocalizedString(@"The input can contain only letters", @""); 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]; } return NO; } return YES; } @end 

AlphaInputValidatorクラスもInputValidatorバリエーションであり、 validateInput:メソッドを実装しています。 NSRegularExpressionオブジェクトで別の正規表現を使用し、エラーコードとメッセージが文字検証に固有であることを除いて、兄弟のようなNumericInputValidator 、コード構造、およびアルゴリズムがあります。 文字のテストに使用する正規表現は「^ [a-zA-Z] * $」です。 有効な文字のセットに小文字と大文字の両方が含まれていることを除いて、彼の仲間の数値検証の表現のように見えます。 ご覧のとおり、どちらのバージョンにも多くの重複コードがあります。 両方のアルゴリズムの構造は似ています。 構造をテンプレートメソッド（第18章を参照）に抽象化して、基本クラスにリファクタリングできます。 InputValidator特定のサブクラスは、 InputValidator定義されたプリミティブ操作をオーバーライドして、一意の情報をテンプレートアルゴリズムに返します。たとえば、 NSErrorオブジェクトの正規表現やさまざまな構築属性などです。これは演習として残します。

これで、アプリケーションで使用できる検証クラスがすでに用意されました。 ただし、 UITextFiel dはそれらについて認識していないため、すべてを理解する独自のバージョンのUITextFieldが必要です。 リスト19-7に示すように、 InputValidatorへの参照とvalidateメソッドを含むUITextFieldサブクラスを作成します。

リスト19-7。 CustomTextField.hのCustomTextFieldクラス宣言

 #import "InputValidator.h" @interface CustomTextField : UITextField { @private InputValidator *inputValidator_; } @property (nonatomic, retain) IBOutlet InputValidator *inputValidator; - (BOOL) validate; @end 

CustomTextFieldは、 InputValidatorへのretain参照をretainプロパティが含まれています。 validateメソッドが呼び出されると、 InputValidatorへの参照を使用して検証が開始されます。 リスト19–8に示す実装でこれを確認できます。

リスト19-8。 CustomTextField.mのCustomTextFieldクラスの実装

 #import "CustomTextField.h" @implementation CustomTextField @synthesize inputValidator=inputValidator_; - (BOOL) validate { NSError *error = nil; BOOL validationResult = [inputValidator_ validateInput:self error:&error]; if (!validationResult) { UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:[error localizedDescription] message:[error localizedFailureReason] delegate:nil cancelButtonTitle:NSLocalizedString(@"OK", @"") otherButtonTitles:nil]; [alertView show]; [alertView release]; } return validationResult; } - (void) dealloc { [inputValidator_ release]; [super dealloc]; } @end 

メッセージ[inputValidator_ validateInput:self
error:&error] 、 validateメソッドで送信されます [inputValidator_ validateInput:self
error:&error] [inputValidator_ validateInput:self
error:&error]リンクinputValidator_ 。 パターンのCustomTextFieldは、 CustomTextFieldが使用するInputValidatorタイプやアルゴリズムの詳細を知る必要がないことです。 したがって、将来、新しいInputValidatorを追加する場合、 CustomTextFieldオブジェクトは同じ方法で新しいInputValidatorを使用します。

したがって、準備作業はすべて完了しました。 リスト19-9に示すように、クライアントがUITextFieldDelegateプロトコルを実装し、タイプCustomTextField 2つのIBOutlets含むIBOutletsあるとしCustomTextField 。

リスト19-9。 StrategyViewController.hのStrategyViewControllerクラス宣言

 #import "NumericInputValidator.h" #import "AlphaInputValidator.h" #import "CustomTextField.h" @interface StrategyViewController : UIViewController <UITextFieldDelegate> { @private CustomTextField *numericTextField_; CustomTextField *alphaTextField_; } @property (nonatomic, retain) IBOutlet CustomTextField *numericTextField; @property (nonatomic, retain) IBOutlet CustomTextField *alphaTextField; @end 

コントローラーにデリゲートメソッド(void)textFieldDidEndEditing:(UITextField *)textFieldを実装させ、そこにチェックを入れることにしました。 このメソッドは、入力フィールドの値が変更され、フォーカスが失われるたびに呼び出されます。 ユーザーが入力を終了すると、リスト19-10に示すように、 CustomTextFieldクラスはこのデリゲートメソッドを呼び出します。

リスト19-10。 デリゲートメソッドtextFieldDidEndEditing：で定義されたクライアントコードは、ストラテジーオブジェクト（InputValidator）を使用してCustomTextFieldのインスタンスを検証します。

 @implementation StrategyViewController @synthesize numericTextField, alphaTextField; // ... //    // ... #pragma mark - #pragma mark UITextFieldDelegate methods - (void)textFieldDidEndEditing:(UITextField *)textField { if ([textField isKindOfClass:[CustomTextField class]]) { [(CustomTextField*)textField validate]; } } @end 

textFieldDidEndEditing:呼び出すときtextFieldDidEndEditing:フィールドの1つで編集が完了すると、このメソッドはtextFieldオブジェクトがCustomTextFieldクラスに属していることを確認します。 もしそうなら、彼は入力されたテキストをチェックするプロセスを開始するために彼にvalidateメッセージを送信します。 ご覧のとおり、これらの条件ステートメントはもう必要ありません。 代わりに、同じ目的のためのはるかに単純なコードがあります。 textFieldがCustomTextFieldであることをさらに確認することを除いて、これ以上複雑なことはありません。

しかし、ちょっと待ってください。 何かがあまり良く見えません。 StrategyViewController定義されているInputValidator numericTextField_およびalphaTextField_正しいInputValidator numericTextField_インスタンスをどのように割り当てることができますか？ リスト19-9 IBOutlet 、両方の入力フィールドがIBOutletとして宣言されています。 他のボタンなどと同様に、 IBOutletを介してInterface Builder View Controllerでそれらを選択できます。 同様に、リスト19–7のCustomTextFieldクラスの宣言では、そのinputValidatorプロパティもIBOutletであるため、Interface Builderで*TextFieldオブジェクトにもInputValidatorインスタンスを割り当てることができます。このように、特定のクラスプロパティをとして宣言すると、Interface Builderの参照リンクを使用してすべてを構築できますIBOutlet。カスタムInterface Builderオブジェクトの使用方法の詳細についてはCoordinatingController、第11章の「Interface Builderでの使用」を参照してください。Mediatorパターンについて説明しています。

おわりに

この章では、戦略パターンの概念と、クライアントがさまざまな関連アルゴリズムを使用するためにこのパターンを使用する方法について説明しました。カスタムチェックの入力チェックの実装例は、UITextFieldさまざまなチェッククラスがオブジェクトの「内部」をどのように変更できるかを示しています。Strategyパターンは、Decoratorパターンに多少似ています（16章と以前の記事）。デコレータはオブジェクトの動作を外部から拡張し、さまざまな戦略がオブジェクト内にカプセル化されます。彼らが言うように、デコレータはオブジェクトの「スキン」と戦略、「インサイド」を変更します。

次の章では、アルゴリズムのカプセル化に関連する別のパターンを見ていきます。カプセル化されたアルゴリズムは、主に個別のオブジェクトとしてコマンドの遅延実行に使用されます。