Composite パターンを例でわかりやすく解説

目的

オブジェクトを木構造に組み立てて、部分と全体の階層を表現します。Composite パターンでは、クライアントが個々のオブジェクトとオブジェクトの集合体を一様に扱えます。Gang of Four（GoF）の書籍にある7つの構造パターンの1つです。

解決する問題

どの項目についても合計サイズを表示しなければならないストレージアプリを想像してください。ファイルにはサイズがあります。フォルダーのサイズは中身すべての合計で、フォルダーにはファイルや他のフォルダーを任意の深さまで入れ子にして含められます。

共通のインターフェイスがないと、木をたどるすべてのコードが、「これはファイルかフォルダーか」と尋ねて、それぞれの場合を処理しなければならず、たいていは何度も同じ再帰を書くことになります。ショートカットや圧縮アーカイブのような新しいノードの種類を加えるには、それらのチェックをすべて探し出して更新することになります。Composite パターンは、再帰をノード自身の中に入れます。

構造と登場要素

TypeScriptでの実装

interface FsNode {
  readonly name: string;
  size(): number;
  print(indent?: string): string[];
}

class FileNode implements FsNode {
  constructor(readonly name: string, private bytes: number) {}
  size(): number { return this.bytes; }
  print(indent = ""): string[] { return [`${indent}${this.name} (${this.bytes})`]; }
}

class Folder implements FsNode {
  private children: FsNode[] = [];
  constructor(readonly name: string) {}
  add(...nodes: FsNode[]): this { this.children.push(...nodes); return this; }
  size(): number { return this.children.reduce((sum, c) => sum + c.size(), 0); }

  print(indent = ""): string[] {
    const lines = [`${indent}${this.name}/ (${this.size()})`];
    for (const child of this.children) lines.push(...child.print(indent + "  "));
    return lines;
  }
}

const root = new Folder("project").add(
  new FileNode("README.md", 120),
  new Folder("src").add(new FileNode("main.ts", 900), new FileNode("util.ts", 300)),
);

// The client treats a single file and a whole tree the same way.
const report = (node: FsNode) => console.log(node.print().join("\n"));
report(root);
// project/ (1320)
//   README.md (120)
//   src/ (1200)
//     main.ts (900)
//     util.ts (300)
report(new FileNode("notes.txt", 42)); // notes.txt (42)

report はノードの種類を一度も確認しません。サイズ0を報告する Symlink のような新しい種類のノードは、FsNode を実装するだけで済みます。

設計上の判断：透過性と安全性

add() や remove() のような子を管理するメソッドは、どこに置くべきでしょうか。GoFの書籍はそのトレードオフを説明しています。

TypeScriptでは、型チェッカーがコンパイル時に間違いを捕捉できるため、通常は安全性を取るアプローチのほうがうまく機能します。

使うべきとき、使わないとき

次の場合はComposite パターンを使います。

• ファイルとフォルダー、コンテナ内のUIウィジェット、メニューとサブメニュー、組織図、図形とグループなど、データが自然に木構造である場合。
• クライアントが、1つのオブジェクトとオブジェクトのグループとの違いを意識せずに済むようにしたい場合。

次の場合は避けます。

• 構造がフラットな場合や、常に1階層の深さしかない場合。単純な配列のほうが簡単です。
• 葉とグループが、まったく異なる操作を必要とする場合。1つのインターフェイスに押し込むと、一部のノードにとっては意味をなさないメソッドができてしまいます。
• 複合体が保持できる子を、特定のノードの型のみに制限する必要がある場合。統一されたインターフェイスのせいで、型システムでそうしたルールを強制するのが難しくなります。

実際の利用例

• DOM：すべての要素とテキストノードは Node です。要素は他のノードを含むことができ、textContent や cloneNode(true) など多くの操作が、単一のノードにも部分木全体にも同じように働きます。
• React、Vue、AngularなどのUIコンポーネントフレームワークは、コンポーネントが他のコンポーネントを描画できる木としてインターフェイスを構築します。
• Java AWTとSwing：Container は Component のサブクラスで他のコンポーネントを保持するため、ボタンでいっぱいのパネルも、それ自体がコンポーネントです。
• コンパイラの抽象構文木、ゲームエンジンのシーングラフ、入れ子のメニューも、すべて同じ考え方に従っています。

関連するパターン

• Iterator パターン：子の保持方法を公開せずに、複合体のノードをたどります。
• Visitor パターン：ノードのクラスを変更せずに、複合体の木に新しい操作（エクスポート、検証、統計）を追加します。
• Decorator パターン：こちらもコンポーネントのインターフェイスを持ち、オブジェクトを再帰的にラップしますが、Decoratorの子はちょうど1つで振る舞いを追加するのに対し、複合体は多くの子を持ち、それらの結果を結合します。
• Builder パターン：複雑なComposite パターンの木を段階的に構築するのによく使われます。
• Chain of Responsibility パターン：ブラウザーのイベントがDOMを上方向にバブリングするように、複合体の親へのリンクを使って、リクエストを子から親に渡すことがよくあります。