そのため、私は現在、Excel ワークシートまたは SharePoint リストからデータを取得し、C# で WatiN と .NET を使用して、自動化された UI テスト用のさまざまなブラウザー コマンドを実行するかなりクールなライブラリを開発しようとしています。ただし、将来のコマンドまたはテストを生成する必要がある可能性がある変更要件をカプセル化しようとする際に、大きな設計上の問題に直面しています。現在、コマンド パラメーター (Excel または SharePoint リストに文字列として格納されている) に基づいて実行する必要がある約 5 つの固有のアクションがありますが、コマンドの数を簡単に拡張可能にし、検証を実行して確認したいと考えています。悪いコマンドはありません。HandleCommand() 関数で 1 つの巨大な switch ステートメントを記述するだけでなく、これを効率的かつ堅牢に実装するのに役立つデザイン パターンの正しい方向を教えてもらえますか? 新しいプログラマーを助けてくれてありがとう！=D
質問する
914 次
2 に答える
4
コマンド パターンを見てコマンドをカプセル化し、ファクトリ パターンを使用してその名前に基づいてコマンド オブジェクトのインスタンスを作成します。ファクトリはリフレクションを使用して、テキストに基づいて作成するコマンドを決定できます。
于 2012-06-08T21:05:26.820 に答える
0
I agree that Builder and Factory Method make sense here. You probably don't want to use the inheritance-based version of Factory Method as described in the "Design Patterns" book by Gamma and co. Just use a static factory method that takes the name of the Command class to instantiate.
于 2012-06-09T13:08:17.247 に答える