Entry

Command パターンを Web アプリで使う意義

2008年12月22日

Command パターンについてゴニョゴニョ考えているんですけれど,これ,濫用されることも多いもんで,採用する際に賛否が分かれたりします。例えば,こちらは,Command パターンの利用に消極的な意見。

そもそもCommandパターンは、Commandを抽象オブジェクトとして一括管理し、例えば
Undo、Redo処理や複数Commandの一括処理等を行うのに適した仕組みをフォローする。
これは、お絵かきソフト等のローカルで動作するプログラムでは、確かに有用だが
Webアプリではどうだろうか?
WebアプリではUndo、Redoの機能はあまり一般的ではないし、処理自身も1セッション
でやりきる単発パターンの繰り返しとなる。
確かに基本ページから全てを掌握できる小規模なシステムにはCommandパターンはうまく
利用できるかもしれない。しかし、大規模かつページ遷移が複雑なWebアプリに採用すると
逆にパターンに縛られ融通が利かなくなる。また、チーム開発においても単体開発・テスト
がやりにくい環境になるように思う。

WebアプリケーションにおけるCommandパターンの採用について

これは,GoF 本が Undo/Redo について書かれているから,その話題を出していると思うんですけれど,Command パターンは Undo/Redo の機能を組み込むためだけにあるわけじゃなかったりします。例えば,Web アプリではログを取ることがあるけれども,Command クラスにロギングメソッドをフックするようにしておけば,呼び元(Client)はログを取っていることを意識しないでトランザクションを開始することができたりもする。

あたしは,Command パターンを割とガツガツと使う方なんですけれど,個人的に Command パターンでしっかり組める設計ってのは,操作集合(の I/F)をきっちり規定できる場合で,全体のフレームワークとしてみても,論理的に密度の高いものができる気がしています。「パターンに縛られ融通が利かなくなる」という批判はよくあるんですけれど,パターンで I/F に縛りを持たせることは,操作を体系付けるには必要なことなわけで,良くも悪くも取れるような気がする。

Command パターンの目的は,「機能を使う人」と「機能の呼び出し方を知っている人」を分離するところにあったりします。分離することで,状況依存で Command を入れ替えたり,複雑なトランザクションを構成したり,(共通)機能を付加したりすることが容易になる。ここら辺を生かした設計が Web アプリにないかというと,ログの場合はもちろん,結構工夫する余地があると思うんですね。

ま,今すぐ出せって言われると,あまり出ないんですけど。柔軟なパターンなだけに,考える余地がかなり多い気がする。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN