Compositeパターンとは？意味・定義・使い方

パターンの構造と機能

Compositeパターンは、主に以下の3つの構成要素から成り立っている。

Component (コンポーネント): LeafとCompositeの共通インターフェースを定義する抽象クラスまたはインターフェースである。クライアントが操作を呼び出す際の窓口となる。例えば、Operation()やdisplay()といった、階層内の全ての要素が実行すべき共通のメソッドを宣言する。また、Composite特有の操作（子要素の追加・削除など）をここに含めるか否かは、設計の安全性と透過性のトレードオフによって決定される。
Leaf (リーフ): 階層構造における最も単純な要素であり、子を持たないオブジェクトである。ファイルシステムにおけるファイルのように、それ以上分割できない「葉」の部分を担う。Componentインターフェースで定義された操作を実装するが、子要素を管理するメソッドは通常、意味を持たない。
Composite (コンポジット): 子要素を持つことができ、Leafオブジェクトまたは他のCompositeオブジェクトを内部に格納するコンテナの役割を果たす。ディレクトリやフォルダに相当する。Compositeは、Componentインターフェースを実装するだけでなく、子要素を保持するためのコレクション構造（リストなど）を持ち、子要素を追加・削除するメソッド（例：add(Component)、remove(Component)）を実装する。Compositeに対する操作が呼び出された際には、自身の子要素それぞれに対し再帰的に同じ操作を委譲する。

この構造により、クライアントはLeafとCompositeの違いを区別する必要がなく、すべてをComponentとして扱える。この性質は「透明性（Transparency）」と呼ばれ、Compositeパターンの最大の機能的特徴である。クライアントは、個別のファイルに対してデータを読み出す操作をするのと全く同じ方法で、フォルダ全体に対してサイズを取得する操作を実行できる。

具体的な使用例・シーン

Compositeパターンは、データを再帰的な階層構造（木構造）として表現する必要があるあらゆる場面で適用される。

1. ファイルシステムとディレクトリ構造

最も典型的な応用例である。ファイルシステムにおいて、ディレクトリ（フォルダ）はCompositeであり、ファイルはLeafである。ディレクトリは他のディレクトリやファイルを内包できるため、これら両方を共通のインターフェース（Component）で操作する必要がある。例えば、getSize() メソッドを呼び出す際、ファイルならば自身のサイズを返し、ディレクトリならば内包するすべてのファイルやサブディレクトリのサイズを再帰的に合計して返す構造がCompositeパターンによって容易に実現される。

2. グラフィカルユーザーインターフェース（GUI）

ウィンドウシステムにおけるコンポーネント構造もCompositeの好例である。ウィンドウ（Composite）は、パネルやボタン、テキストボックスなどの部品（Leaf）や、さらなるコンテナ（Composite）を内包する。描画（draw()）やクリックイベントのハンドリングといった操作は、コンテナに対して行われた場合、その内部の全ての子要素に対して再帰的に伝播される。これにより、開発者は個々の部品と全体としてのウィンドウ構造を統一的に扱える。

3. 組織図や部品表（BOM）

企業の組織構造や、製造業における製品の部品表（Bill of Materials, BOM）のように、全体が部分の集合であり、その部分もまたさらに小さな部分から構成されているモデル化にも適している。組織図において、部門全体（Composite）と個々の従業員（Leaf）を同一のインターフェースで管理することで、たとえば「全員の給与合計」や「部門全体のパフォーマンス評価」といった集計操作を簡単に実行できる。

メリット・デメリットと設計上の考慮点

メリット (利点)

透過性（Transparency）の実現: クライアントコードは、操作対象がLeafであるかCompositeであるかを区別する必要がなく、シンプルになる。これにより、コードが理解しやすく、保守性が向上する。
階層構造の容易な操作: 再帰的な処理がパターンに組み込まれるため、ツリー構造全体のトラバースや集計操作が、実装側で自動的に委譲される形で簡潔に記述できる。
新しい要素の追加容易性: 新しい種類のLeafまたはCompositeを追加する際、既存の構造やクライアントコードを変更することなく、容易に拡張できる（オープン・クローズドの原則に合致）。

デメリット (欠点)

安全性のトレードオフ: Componentインターフェースに、子要素の追加・削除といったComposite特有の操作を含めると、Leafオブジェクトがそれらのメソッドを実装する必要が生じる。Leafにとって意味のない操作を実装しなければならない点（通常は例外を投げるか何もしない実装となる）は、設計の「安全性（Safety）」を損なう要因となる。
過剰な一般化の可能性: すべての要素を統一的に扱うために、不必要なインターフェースを定義したり、デザインが複雑になりすぎたりする可能性がある。特定のユースケースでのみ階層構造が必要な場合は、本パターンがオーバーエンジニアリングになることもある。

設計上の考慮点：安全性と透過性の選択

前述のデメリットを回避するため、Compositeパターンには二つの実装方針が存在する。

透過的なアプローチ: Componentに子管理メソッドを含める。クライアントはすべてをComponentとして扱えるが、Leafに対して無意味なメソッドを呼び出すリスクがある。
安全なアプローチ: Componentには共通操作のみを定義し、子管理メソッドはCompositeクラスのみに定義する。これにより、Leafに対して誤った操作を呼び出すことはなくなるが、クライアントがCompositeを操作する際に型キャスト（Compositeへの変換）が必要となり、透過性が失われる。

一般的には、システム全体で高い透過性が求められる場合には透過的なアプローチが、型の安全性が重視され、操作ミスを防ぎたい場合には安全なアプローチが選択される。

CompositeパターンとDecoratorパターンは、しばしば混同されがちだが、目的が異なる。Compositeパターンは全体と部分の構造を定義し、透過的な操作を実現する。一方、Decoratorパターンはオブジェクトに新しい責任や機能を動的に付加することに焦点を当てる。両パターンは構造が類似しており（両者とも共通のインターフェースを持ち、コンテナは他のオブジェクトをラップする）、特にComponentクラスを抽象化する点で共通点を持つが、Decoratorは一般に単一のオブジェクトをラップするのに対し、Compositeはオブジェクトのコレクションを扱う点で明確に区別される。

由来・語源

Composite（コンポジット）は英語で「複合体」「合成物」を意味する単語である。このデザインパターンは、ソフトウェア設計における古典的な問題、すなわち、単純な要素（葉：Leaf）と、その要素や他の複合体を内包する容器（複合体：Composite）を、いかに統一的に扱うかという課題を解決するために考案された。

本パターンは、1994年に出版されたエリック・ガンマらによる書籍『Design Patterns: Elements of Reusable Object-Oriented Software』（通称GoF：Gang of Four）において、構造に関するデザインパターンの一つとして正式に定義された。このパターンの核心は、「再帰的な構造の要素すべてに対し、共通の抽象的なインターフェースを提供すること」にある。これにより、システム内の階層構造の管理が極めて容易になり、特に実行時に構造が動的に変化するシステムにおいて高い効果を発揮する。

使用例

(記述募集中)

Compositeパターン