👩🏾‍💼 🤟 👁‍🗨 戦略（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つの側面に焦点を当てています。

入力フィールドの数値データと、以前に作成されたNSRegularExpression

オブジェクトとの一致数をチェックします。使用した正規表現は「^ [0–9] * $」です。これは、行全体の先頭（「^」で示される）および末尾（「$」で示される）から、数字のみ（「[0–9]で示される）を含むセットの0個以上の文字（「*」で示される）が必要であることを意味します"）。
一致するものがまったくない場合、「入力には数値のみを含めることができます」というメッセージを含む新しい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章と以前の記事）。デコレータはオブジェクトの動作を外部から拡張し、さまざまな戦略がオブジェクト内にカプセル化されます。彼らが言うように、デコレータはオブジェクトの「スキン」と戦略、「インサイド」を変更します。

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

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

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

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

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

おわりに

More articles: