このビデオ[@ 7:50] によると、Google はリクエスト処理 API の上にコマンド パターンを使用することを推奨しています。そのパターンを実装する便利なプロジェクトgwt-dispatchもあります。
gwt-dispatch のドキュメントによると、コマンドごとに 4 つのクラスを作成する必要があります。
私のサービス API には 8 つの BSO にまたがる 100 のメソッドがあると仮定します。400 近くの新しいクラスを作成する理由を誰か説明してもらえますか? このパターンはどのような素晴らしさを買いますか?
コマンド パターンを使用する正当な理由の 1 つは、コマンド オブジェクトを他のデリゲートに渡したい場合です。そのため、すべての引数をコピーする代わりに、コマンド オブジェクトを渡すだけの方が簡単です。また、gwt-dispatch のロールバック機能 (または Eclipse の UndoableOperations などの元に戻す/やり直し機能) にも役立ちます。
さまざまなコンストラクターやコマンドのサブクラスを使用して、いくつかのバリエーションのコマンドを提供すると便利です。
常にパターンを使用することはお勧めしませんが、パターンを使用しない場合は、思ったほど節約できません: いずれにせよ結果オブジェクトが必要になることがよくあります。また、同じ戻りオブジェクトを再利用することもできます。それ以外の場合は、コマンドと結果に同じオブジェクトを使用できます。
モジュールは複数のコマンドに使用できます。