PR

CompositeパターンとCommandパターンの事例

2009年5月22日(金)
中川 三千雄

着目するポイント

 一般的なChain of ResponsibilityパターンはConcreteHandler役が「チェーン構造」と「要求に対する処理」の両方の責務を持つように設計します。しかし、「チェーン構造」は特殊なケースを除いては同じ操作と構造になるはずです。なぜなら「チェーン構造」の役割はConcreteHandler役をチェーンにつないだり、変更したり、削除したりできればよいからです。

 一方、「要求に対する処理」は要求ごとに処理を用意する必要があります。よって、それらの処理は重複することがなく、すべて異なります。

 汎用的なフレームワークを実現する以上、「チェーン構造」に関する機能はフレームワーク側で提供し、フレームワークの利用者は「要求に対する処理」に集中してプログラミングできるようにするべきです。

 今回は「チェーン構造」と「要求に対する処理」を切り離すところに着目して、汎用的なフレームワークを作成します。

チェーン構造をツリー構造に置き換える

 まずは図2-1をご覧ください。Chain of Responsibilityパターンのチェーン構造はConcreteHandler役のスーパークラスであるHandler役が持っています。Handler役は自分自身の関連を持つことでチェーン構造を実現しています。そのためサブクラスであるConcreteHandler役にもその特性が継承されます。

 ConcreteHandler役からチェーン構造を取り除くため、Handler役のチェーン構造の部分にCompositeパターンを適用します。Compositeパターン適用後のクラス図を見るとComponent役とComposite役の関係で再帰的な構造を実現していることがわかります。その再帰的な構造は、図2-2のようなツリー構造に変化します。その図を見てわかるようにComposite役がツリー構造を管理する役割を持ち、Leaf役が要求に対する処理の役割を持つように分かれます。

 Chain of Responsibilityパターンのチェーン構造を、Compositeパターンを適用したツリー構造に置き換えることで、ConcreteHandler役が抱えていた「チェーン構造」と「要求に対する処理」の両方の責務を持つ問題を解決できます。

株式会社オージス総研
株式会社オージス総研アドバンストモデリングソリューション部アーキテクトチーム兼エンタープライズオープンソースセンター所属。これまでに2社の独立系SI企業で経験を積み、現在に至る。オージス総研では、フレームワークの設計/開発や開発プロセス支援など、アーキテクトとしてプロジェクトに参画する。また、オージス総研のコミュニティー「オブジェクトの広場」にも参加している。
オブジェクトの広場 http://www.ogis-ri.co.jp/otc/hiroba/

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています