コマンドパターンとストラテジパターン
PofEAA 読書会で話題になったので。
シンタックス的に利用する機構（＝多態性）が同じこの2つのパターン。 思うところをつれづれと書いてみたりする。
コマンドパターン
マクロでみた意味的には、そのインスタンスにコマンド実行（処理実行）に必要なデータと、ロジックを詰め込むようなイメージ。
必要なデータとロジックがインスタンスにパッキングされているがゆえに、1番目の処理Aと2番目の処理Bと3番目の処理Aを実行したい場合は、処理Aに対応したインスタンス＋処理Bに対応したインスタンス+処理Aに対応したインスタンスをキューなどに並べておき、順次実行すればよいこととなる。 コマンド実行のトリガを与えるクライアントが、コマンドのインスタンス以外に気を使わなくて良い点がポイント。コマンドクラスが、そのコマンド実行に必要なデータ、ロジックをカプセル化して保持しているから。 さらに、コマンド実行を取り消す（アンドゥ）ために必要なデータと、ロジックも詰め込むようにすることで、アンドゥ処理が可能となる。
OOPの意味的な観点でいうと、コマンドパターンは「インスタンス」に意味がある。
具体的には、同じMoveCommand(dx, dy)でも、new MoveCommand(5,10)と new MoveCommand(-10,20)は、処理内容が異なる。
多態性は、クライアントが異なるコマンド種別を統一的に実行できるために活用される。
Command cmd = queue.getCommand(); cmd.execute()
ストラテジパターン
マクロで見た意味的には、ロジックをプラガブルにしたようなイメージ。インスタンスレベルで保持するデータにはあまり重きを置かれていない。
クラスとか、インスタンスとかが本質的な意味でポイントにはならず、プラガブルな構成要素的な観点を持つものであればよい。
OOPの意味的な観点でいうと、ストラテジパターンは「インスタンス」にあまり意味がない。
プラガブルな機構を実現できれば、ストラテジが提供するメソッドはクラスメソッドでもかまわない。（暴論気味・・・）
多態性は、クライアントの統一的な利用というよりは、プラグ差し替えを実現するための機構として利用される。本質は利用形態の一元化ではなく、差し替え可能性にある。
最近のコマンドパターン
StrutsのActionFormをコマンドパターンとか言う人もいて、 ちょっと違和感を感じていたりもするけど、まぁいいかも。という気もする。
HTTPリクエストの内容を、1つのインスタンスにパックしており、かつ、ビジネスレイヤの呼び出しというロジックも（一応）実装しているから。上記に話とも一応対応している。
が、キューに格納されるでもなく、アンドゥ機構を提供するでもない点がちょっと引っかかるかな。コマンドパターンのご利益を活用しているわけではないということ。
executeメソッドを実装しているクラス群が何でもコマンドパターンというのは違うと思いますがね。 インスタンスにデータとロジックがパッキングされていることがポイント。 と思いますよー。と、気弱にまとめてみた。
