Compositeパターン調査ドキュメント

調査目的

Compositeパターン(コンポジットパターン)に関する包括的な調査を行い、Perl入学式卒業レベルの読者向けシリーズ記事作成の基盤となる情報を収集する。

調査対象: GoF定義、構造、適用場面、SOLID原則との関係、他パターンとの比較、Perl/Moo実装、アンチパターン
想定読者: Perl入学式卒業レベル、Perl/Mooでデザインパターンを学習したいエンジニア
調査実施日: 2026年01月20日

1. Compositeパターンの定義と本質

1.1 GoFによる定義と意図(Intent)

要点:

定義: オブジェクトをツリー構造に組み立てることで部分-全体階層(part-whole hierarchies)を表現する。Compositeパターンは、個別オブジェクト(Leaf)と複合オブジェクト(Composite)をクライアントが同一に扱えるようにする
意図: クライアントが単一オブジェクトとオブジェクトの集合を統一的に扱えるようにする
分類: 構造パターン(Structural Pattern)
キーフレーズ: “Compose objects into tree structures to represent part-whole hierarchies”

根拠:

Gang of Four(GoF)の『Design Patterns: Elements of Reusable Object-Oriented Software』における正式定義
Compositeパターンの本質は「統一的なインターフェース」による「透過的な扱い」にある
再帰的な構造(ツリー)を扱う際に、クライアントコードが個別と集合を区別する必要がなくなる

出典:

Composite pattern - Wikipedia: https://en.wikipedia.org/wiki/Composite_pattern
Composite - refactoring.guru: https://refactoring.guru/design-patterns/composite
GOF Design Patterns : Composite - Haris Space: https://www.harisspace.com/docs/lld/gof/structural/composite/
Composite Pattern (with Example) - HowToDoInJava: https://howtodoinjava.com/design-patterns/structural/composite-design-pattern/

信頼度: 10/10(GoF公式定義に基づく複数の権威ある情報源からの一致した記述)

1.2 パターンの構造(Structure)

要点:

Compositeパターンは4つの主要コンポーネントで構成される：

コンポーネント	役割	説明
Component	共通インターフェース	LeafとCompositeの両方に共通する操作を定義。場合によっては子要素管理メソッドも含む
Leaf	リーフ(末端ノード)	ツリー構造の末端。子要素を持たない。操作を直接実装
Composite	コンポジット(複合ノード)	子要素(LeafまたはComposite)を持つ。操作を子要素に委譲または集約
Client	クライアント	Component インターフェースを通じて操作。LeafかCompositeかを意識しない

構造図(テキスト表現):

1
2
3
4
5
6
7
Component (interface/role)
   |
   +-- Leaf (子を持たない末端ノード)
   |
   +-- Composite (子を持つ複合ノード)
          |
          +-- children: [Component, Component, ...]

根拠:

GoF書籍のクラス図とパターン説明に基づく標準的な構造
Component、Leaf、Composite、ClientはGoF標準の参加者(Participants)
Compositeは子要素への参照をコレクションとして保持し、操作を再帰的に処理

出典:

Understanding the Composite Design Pattern - DEV Community: https://dev.to/syridit118/understanding-the-composite-design-pattern-a-comprehensive-guide-with-real-world-applications-4855
Composite (GoF) | Design Patterns: https://iretha.github.io/design-patterns/structural/composite
What is the Composite Pattern? | System Overflow: https://www.systemoverflow.com/learn/structural-patterns/composite-pattern/what-is-the-composite-pattern

信頼度: 10/10(複数の信頼できる技術文献における一貫した構造定義)

2. Compositeパターンの適用場面

2.1 どのような問題を解決するか

要点:

Compositeパターンは以下の問題を解決する：

問題	解決方法
部分-全体階層の表現が困難	ツリー構造で自然に表現。LeafとCompositeを同一インターフェースで扱う
クライアントコードでの型チェック乱立	統一インターフェースにより、if/elseによる型判定が不要
階層構造への操作の複雑化	再帰的な操作委譲により、クライアントコードがシンプルに
新しい種類のLeaf/Compositeの追加	開放閉鎖原則(OCP)に従い、既存コードを変更せずに拡張可能

根拠:

従来のアプローチでは、個別オブジェクトと集合を区別するために、クライアントコードに型判定や条件分岐が増える
Compositeパターンでは、Componentインターフェースを介して透過的に操作できるため、クライアントコードが簡潔になる
新しい種類のLeafやCompositeを追加しても、既存のクライアントコードに影響がない

出典:

Composite Design Pattern - GeeksforGeeks: https://www.geeksforgeeks.org/system-design/composite-method-software-design-pattern/
Composite Pattern (with Example) - HowToDoInJava: https://howtodoinjava.com/design-patterns/structural/composite-design-pattern/

信頼度: 9/10(複数の技術文献で共通して説明されている問題解決アプローチ)

2.2 具体的なユースケース

要点:

ユースケース	説明	Leaf例	Composite例
ファイルシステム	ディレクトリとファイルの階層構造	File	Directory
GUIコンポーネント	ウィジェットとコンテナの階層	Button, Label	Panel, Window
組織図	従業員と部門の階層	Employee	Department
メニューシステム	メニュー項目とサブメニュー	MenuItem	Menu
ドキュメントオブジェクトモデル	XML/HTML要素とグループ	TextNode	Element
グラフィックエディタ	図形とグループ化された図形	Circle, Rectangle	Group

根拠:

ファイルシステムはCompositeパターンの最も典型的な例として広く知られる
GUIフレームワークの多くはCompositeパターンを内部的に使用(Swingのコンポーネント階層など)
組織図やメニューシステムは、実世界の階層構造を直接的にモデル化できる例

出典:

Understanding the Composite Pattern for Tree-Like Structures: https://procodebase.com/article/understanding-the-composite-pattern-for-tree-like-structures
Mastering Composite Pattern: https://www.numberanalytics.com/blog/ultimate-guide-composite-pattern-software-design
Composite Design Pattern: Treat Objects and Collections Uniformly: https://themorningdev.com/composite-design-pattern/

信頼度: 10/10(実装例が多数確認できる実績あるユースケース)

2.3 いつ使うべきか、いつ使うべきでないか

要点:

使うべき場合:

部分-全体階層が自然にツリー構造で表現できる場合
個別オブジェクトとオブジェクト集合を統一的に扱いたい場合
階層構造を動的に変更する必要がある場合
操作を階層全体に伝播させたい場合

使うべきでない場合:

シナリオ	理由
フラットまたは2階層のみの構造	パターンの複雑性が不要な抽象化を導入
オブジェクト間で著しく異なるインターフェース	統一インターフェースの強制が不自然
パフォーマンスクリティカルなアプリケーション	深いツリーの再帰的走査がオーバーヘッドに
階層関係がない場合	部分-全体関係が存在しない場合は不適切

根拠:

Compositeパターンは階層構造に特化したパターンであり、フラット構造には過剰
統一インターフェースを強制することで、一部のオブジェクトに無意味なメソッドが含まれる可能性
深いツリー構造での頻繁な走査は、パフォーマンスに影響を与える

出典:

When should I use composite design pattern? - Stack Overflow: https://stackoverflow.com/questions/5334353/when-should-i-use-composite-design-pattern
Composite Design Pattern - GeeksforGeeks: https://www.geeksforgeeks.org/system-design/composite-method-software-design-pattern/

信頼度: 9/10(実装経験に基づく共通認識)

3. SOLID原則との関係

3.1 開放閉鎖原則(Open/Closed Principle: OCP)との関連

要点:

OCP定義: ソフトウェアエンティティは拡張に対して開いているが、変更に対して閉じているべき
Compositeとの関係: 新しい種類のLeafやCompositeを追加する際、既存のComponentインターフェースやクライアントコードを変更する必要がない
具体例: ファイルシステムに新しい種類のファイル(例：SymbolicLink)を追加しても、既存のDirectoryやFileクラス、クライアントコードは変更不要

根拠:

Compositeパターンは、Componentインターフェースに依存することで、新しいコンクリートクラスを追加しても既存コードに影響を与えない
これはOCPの「拡張に開き、変更に閉じる」という原則を直接的にサポート

出典:

SOLID Design Principles and Design Patterns with Examples: https://dev.to/burakboduroglu/solid-design-principles-and-design-patterns-crash-course-2d1c
Open Closed Principle and Liskov substitution principle - GitHub: https://github.com/tarunprof4/Solid-Design-Principles

信頼度: 10/10(SOLID原則とComposite関係は広く認知された理論的基盤)

3.2 リスコフの置換原則(Liskov Substitution Principle: LSP)との関連

要点:

LSP定義: サブタイプは、そのベースタイプと置換可能であるべき
Compositeとの関係: LeafとCompositeはどちらもComponentとして置換可能。クライアントはどちらを使っても正しく動作する
潜在的なLSP違反: Componentインターフェースに子要素管理メソッド(add(), remove())を含めると、Leafでこれらのメソッドが無意味になり、LSP違反の可能性

根拠:

Compositeパターンの意図はLSPをサポートするが、実装方法によってはLSP違反が発生する
Leafがadd()メソッドを持つと、呼び出し時に例外を投げるか何もしない(no-op)必要があり、これはLeafがCompositeと完全に置換可能でないことを意味する
ベストプラクティスは、子要素管理メソッドをCompositeのみに限定するか、インターフェース分離原則(ISP)に従って分離すること

出典:

Is the Composite Pattern SOLID? - Stack Overflow: https://stackoverflow.com/questions/1579520/is-the-composite-pattern-solid
Liskov Substitution Principle in Java - Baeldung: https://www.baeldung.com/java-liskov-substitution-principle
SOLID Series: Liskov Substitution Principle (LSP): https://blog.logrocket.com/liskov-substitution-principle-lsp/

信頼度: 9/10(LSPとCompositeの関係は議論があるが、潜在的な違反は広く認知されている)

3.3 依存性逆転の原則(Dependency Inversion Principle: DIP)との関連

要点:

DIP定義: 上位モジュールは下位モジュールに依存すべきでない。両方とも抽象に依存すべき
Compositeとの関係: クライアント(上位)とLeaf/Composite(下位)は、どちらもComponentインターフェース(抽象)に依存する
具体例: クライアントコードはComponentインターフェースのみを知り、具体的なLeafやCompositeクラスの実装詳細には依存しない

根拠:

Compositeパターンは、抽象(Componentインターフェース)への依存を通じて、クライアントと具体的な実装を分離
これによりDIPの原則が満たされ、コードの柔軟性と保守性が向上

出典:

System Design: Dependency Inversion Principle - Baeldung: https://www.baeldung.com/cs/dip
Understanding the dependency inversion principle (DIP): https://blog.logrocket.com/dependency-inversion-principle/
Dependency Inversion Principle - DeepWiki: https://deepwiki.com/microwind/design-patterns/5.5-dependency-inversion-principle

信頼度: 10/10(DIPとCompositeの関係は明確で、複数の技術文献で一貫して説明されている)

4. 他のデザインパターンとの関係

4.1 Decoratorパターンとの比較

要点:

観点	Composite	Decorator
目的	部分-全体階層の表現	動的な機能追加
構造	親子関係(ツリー)	ラッパー関係(チェーン)
関係性	1対多(親が複数の子を持つ)	1対1(ラッパーが1つの被ラッパーを持つ)
用途例	ファイルシステム、GUI階層	ログ追加、認証追加
共通点	どちらも再帰的構成を使用	Componentインターフェースを共有

根拠:

どちらも構造パターンで、再帰的なオブジェクト合成を使用する点で類似
Compositeは「集合」を扱い、Decoratorは「拡張」を扱う点で目的が異なる
Compositeの親ノードは複数の子を持つが、Decoratorは通常1つのオブジェクトをラップ

出典:

Composite Design Pattern vs. Decorator Design Pattern: https://thisvsthat.io/composite-design-pattern-vs-decorator-design-pattern
Week 4 - Structural Patterns: The Decorator and Composite Patterns: https://github-pages.senecapolytechnic.ca/sed505/Week4/Week4.html
Design Pattern • Composite vs Decorator | KapreSoft: https://www.kapresoft.com/software/2023/12/26/design-pattern-composite-vs-decorator.html

信頼度: 10/10(両パターンの比較は広く議論され、明確に区別されている)

4.2 Iteratorパターンとの組み合わせ

要点:

Iteratorとの関係: Compositeのツリー構造を走査するために、Iteratorパターンを組み合わせることが一般的
利点: クライアントがツリーの内部構造を知らずに、統一的な方法で全要素を巡回できる
実装例: CompositeがIteratorを返すメソッドを提供し、深さ優先探索(DFS)や幅優先探索(BFS)を実装

根拠:

ツリー構造の走査は頻出する操作であり、Iteratorパターンと自然に統合できる
IteratorパターンはGoFでもCompositeとの組み合わせが推奨されている

出典:

The Composite Design Pattern - GitHub Pages: http://stg-tud.github.io/eise/WS11-EiSE-16-Composite_Design_Pattern.pdf
Design Patterns - Ravindra College of Engineering for Women: https://www.recw.ac.in/v1.8/wp-content/uploads/2021/10/DP-UNIT-3.pdf

信頼度: 9/10(実装例が多数あり、実用的な組み合わせとして確立)

4.3 Visitorパターンとの組み合わせ

要点:

Visitorとの関係: Compositeのツリー構造に対して、新しい操作を追加する際にVisitorパターンを使用
利点: ツリー構造のクラスを変更せずに、新しい操作(エクスポート、検証、レンダリングなど)を追加できる
実装例: ComponentにVisitorを受け入れるaccept(Visitor)メソッドを定義し、Visitorが各ノードを訪問して操作を実行

根拠:

Visitorパターンは、データ構造(Composite)とアルゴリズム(Visitor)を分離するため、OCPに従って機能を拡張できる
GoFでもCompositeとVisitorの組み合わせが推奨されている

出典:

Composite and Visitor Example - Tables and Expressions - OOXS: http://www.ooxs.be/EN/java/design-patterns/Composite%20and%20Visitor.html
Visitor - refactoring.guru: https://refactoring.guru/design-patterns/visitor
C++ example of implementation composite and visitor pattern together: https://stackoverflow.com/questions/5441274/c-example-of-implementation-composite-and-visitor-pattern-together

信頼度: 10/10(GoFでも推奨され、実装例が豊富)

4.4 Flyweightパターンとの組み合わせ

要点:

Flyweightとの関係: Compositeのツリー構造で、多数の類似したLeafノードが存在する場合、Flyweightパターンでメモリ使用量を削減
利点: 同じ内部状態を持つLeafノードを共有し、メモリ効率を向上
実装例: 同じ属性を持つLeafオブジェクトを1つだけ作成し、複数のCompositeから参照

根拠:

大規模なツリー構造では、多数の類似したノードが存在する可能性があり、Flyweightでメモリ最適化が可能
グラフィックエディタやゲームエンジンなどで実用的な組み合わせ

出典:

Composite Pattern (with Example) - HowToDoInJava: https://howtodoinjava.com/design-patterns/structural/composite-design-pattern/
Objects Composite Patterns in Systems with Many C: https://leaders.tec.br/pdf/en/f38d34.pdf

信頼度: 8/10(理論的には有効だが、実装例は限定的)

5. Perlでの実装における考慮事項

5.1 Mooでの実装パターン

要点:

Perl/Mooでは、以下のアプローチでCompositeパターンを実装できる：

基本的な実装(Role + has):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
# 言語: perl
# バージョン: 5.36以上
# 依存: Moo(cpanm Mooでインストール)

# Component (Role)
package Component;
use v5.36;
use Moo::Role;

requires 'operation';

1;

# Leaf
package Leaf;
use v5.36;
use Moo;

with 'Component';

has name => (is => 'ro', required => 1);

sub operation ($self) {
    return "Leaf: " . $self->name;
}

1;

# Composite
package Composite;
use v5.36;
use Moo;

with 'Component';

has children => (
    is      => 'rw',
    default => sub { [] },
);

sub add ($self, $component) {
    push @{ $self->children }, $component;
}

sub operation ($self) {
    return "Composite: [" . join(", ", map { $_->operation } @{ $self->children }) . "]";
}

1;

# 使用例
use Leaf;
use Composite;

my $leaf1 = Leaf->new(name => 'Leaf1');
my $leaf2 = Leaf->new(name => 'Leaf2');
my $composite = Composite->new;
$composite->add($leaf1);
$composite->add($leaf2);

say $composite->operation;
# 出力: Composite: [Leaf: Leaf1, Leaf: Leaf2]

根拠:

MooのMoo::RoleでComponentインターフェースを定義し、requiresで必須メソッドを宣言
has属性で子要素のコレクションを保持
Perlの配列とmap関数を活用して、再帰的な操作を簡潔に実装

出典:

OOP with Moo - Perl Maven: https://perlmaven.com/oop-with-moo
Moo - Minimalist Object Orientation (with Moose compatibility): https://metacpan.org/pod/Moo
Perl (with Moose) implementations of the Gang of Four Design Patterns: https://github.com/jeffa/DesignPatterns-Perl

信頼度: 9/10(Moo公式ドキュメントと実装例に基づく)

5.2 Roleの活用方法

要点:

Roleの利点: インターフェース定義と実装の分離、多重継承の問題回避、テスト容易性の向上
Compositeでの活用: ComponentをMoo::Roleで定義し、requiresで必須メソッドを明示
型チェック: isaやdoesでComponentロールを実装しているか確認可能

ベストプラクティス:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# Componentロール
package Component;
use v5.36;
use Moo::Role;

requires 'operation';

# オプション: デフォルト実装
sub display ($self) {
    say $self->operation;
}

1;

# Compositeでの型チェック
package Composite;
use v5.36;
use Moo;
use Types::Standard qw(ArrayRef ConsumerOf);

with 'Component';

has children => (
    is      => 'rw',
    isa     => ArrayRef[ConsumerOf['Component']],
    default => sub { [] },
);

sub add ($self, $component) {
    die "Component must consume 'Component' role" unless $component->does('Component');
    push @{ $self->children }, $component;
}

sub operation ($self) {
    return "Composite: [" . join(", ", map { $_->operation } @{ $self->children }) . "]";
}

1;

根拠:

Types::Standardを使って、子要素がComponentロールを実装していることを型レベルで保証
doesメソッドでロールの実装をランタイムチェック
Roleのデフォルト実装で共通処理を提供

出典:

Moo::Role - Minimal Object Orientation support for Roles: https://metacpan.org/pod/Moo::Role
Object Oriented Programming in Perl - The Perl Beginners’ Site: https://perl-begin.org/topics/object-oriented/

信頼度: 9/10(Mooのベストプラクティスに基づく)

5.3 Perlの多態性の活用

要点:

Perlの多態性: ダックタイピングを基本とするが、Mooでは明示的な型チェックも可能
メソッドディスパッチ: Perlのメソッド解決順序(MRO)により、継承チェーン全体を探索
配列とmap: Perlの配列とmap関数を活用して、子要素への操作を簡潔に記述

実装例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# 深さ優先探索(DFS)の実装例
sub traverse_dfs ($self, $callback) {
    $callback->($self);
    
    if ($self->can('children')) {
        for my $child (@{ $self->children }) {
            $child->traverse_dfs($callback);
        }
    }
}

# 使用例
$composite->traverse_dfs(sub ($node) {
    say $node->operation;
});

根拠:

Perlのcanメソッドで、オブジェクトがメソッドを持つか動的に確認
再帰的な処理をサブルーチンとして簡潔に実装
コールバックを使って、走査時の処理を柔軟に変更可能

出典:

Object Oriented Perl using Moose: https://perlmaven.com/object-oriented-perl-using-moose

信頼度: 8/10(Perlの言語機能を活用した実装パターン)

6. 競合記事分析

6.1 主要な日本語・英語記事

要点:

サイト	言語	特徴	URL
Refactoring Guru	英語/日本語	図解豊富、多言語コード例	https://refactoring.guru/design-patterns/composite
GeeksforGeeks	英語	実装例充実、初学者向け	https://www.geeksforgeeks.org/system-design/composite-method-software-design-pattern/
Wikipedia	英語/日本語	理論的背景、歴史的文脈	https://en.wikipedia.org/wiki/Composite_pattern
DEV Community	英語	実践的な解説、コミュニティ	https://dev.to/syridit118/understanding-the-composite-design-pattern-a-comprehensive-guide-with-real-world-applications-4855
HowToDoInJava	英語	Java実装中心	https://howtodoinjava.com/design-patterns/structural/composite-design-pattern/

根拠:

Refactoring Guruは日本語版もあり、視覚的に分かりやすい解説で初学者に人気
GeeksforGeeksは実装例が充実しており、実践的な学習に適している
Wikipediaは理論的背景が詳しく、学術的な理解に有用

出典:

上記表中のURL参照

信頼度: 10/10(各サイトを直接確認)

6.2 どのような題材で解説されているか

要点:

題材	使用サイト	特徴
ファイルシステム(File/Directory)	ほぼ全サイト	最も一般的な例。直感的で理解しやすい
GUIコンポーネント(Widget/Container)	Refactoring Guru、DEV	実用的で視覚的に理解しやすい
図形エディタ(Shape/Group)	Wikipedia、HowToDoInJava	グラフィック処理の文脈で説明
組織図(Employee/Department)	GeeksforGeeks	ビジネスドメインでの応用例

根拠:

ファイルシステムは誰もが日常的に使う概念であり、ツリー構造のイメージがしやすい
GUIコンポーネントは実装経験者にとって具体的でイメージしやすい
図形エディタはグラフィック処理のコンテキストで自然

信頼度: 10/10(各サイトの記事内容を確認)

6.3 差別化のポイント

要点:

既存記事の傾向:

Java/C++/Pythonでの実装例が中心
理論的な説明に重点
静的型付け言語の観点からの解説

差別化の機会:

差別化軸	アプローチ
言語	Perl/Mooでの実装(既存記事にはほぼ存在しない)
読者層	Perl入学式卒業レベル(初学者に特化)
題材	Perl/Webコンテキスト(例：ルーティング設定、テンプレート構造)
段階的学習	既存の成功パターン(Prototype、State、Factory Methodシリーズ)を踏襲
SOLID原則	LSP違反の可能性など、実装上の注意点を明示

根拠:

CPANやGitHub上でもCompositeパターンのPerl実装例は限定的
既存のシリーズ記事(Prototype、State、Factory Method)で確立された「段階的に理解する」アプローチが読者に好評
Perl特有のダックタイピングとRoleの組み合わせは、他言語とは異なる実装アプローチ

信頼度: 9/10(既存記事の調査とサイト内記事の分析に基づく)

7. 学習者が陥りやすい誤解・アンチパターン

7.1 循環参照の問題

要点:

問題: Compositeが子要素を持ち、その子要素が親を参照すると、循環参照が発生
影響: メモリリーク、無限再帰、ガベージコレクションの阻害
回避策: 子要素が親を参照しない設計、弱参照(weak reference)の使用、走査時に訪問済みセットを保持

実装例(Perlでの回避):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# 弱参照を使った循環参照の回避
package Composite;
use v5.36;
use Moo;
use Scalar::Util qw(weaken);

with 'Component';

has children => (is => 'rw', default => sub { [] });
has parent   => (is => 'rw', weak_ref => 1);  # 弱参照

sub add ($self, $component) {
    push @{ $self->children }, $component;
    $component->parent($self);  # 自動的に弱参照化
}

1;

根拠:

循環参照はリファレンスカウント方式のGCでメモリリークの原因となる
PerlのScalar::Util::weakenまたはweak_refオプションで弱参照を作成可能
ツリー走査時に訪問済みノードを記録することで、無限ループを回避

出典:

How to Handle Circular Dependencies: A Comprehensive Guide: https://algocademy.com/blog/how-to-handle-circular-dependencies-a-comprehensive-guide/
1. Anti-patterns and Best Practices | Apex Design Patterns: https://subscription.packtpub.com/book/programming/9781782173656/6/ch06lvl1sec49/circular-dependencies

信頼度: 9/10(実装上の一般的な問題として広く認識されている)

7.2 過度な抽象化のリスク

要点:

問題: Componentインターフェースを過度に一般化し、すべての可能な操作を含めようとする
影響: インターフェースの肥大化、Leafでの無意味なメソッド実装、LSP違反
症状: Leafクラスで多数のメソッドが「何もしない」または例外を投げる

ベストプラクティス:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# 悪い例: 全メソッドをComponentに含める
package Component;
use v5.36;
use Moo::Role;

requires 'operation', 'add', 'remove', 'get_child';  # Leafには不要

# 良い例: インターフェース分離
package Component;
use v5.36;
use Moo::Role;

requires 'operation';

package CompositeInterface;
use v5.36;
use Moo::Role;

with 'Component';
requires 'add', 'remove', 'get_child';

根拠:

インターフェース分離原則(ISP)に従い、クライアントが使わないメソッドへの依存を避ける
LeafとCompositeで明確に異なるメソッドは、別のRoleに分離すべき

出典:

Composite - refactoring.guru: https://refactoring.guru/design-patterns/composite
Understanding the Composite Design Pattern - DEV: https://dev.to/syridit118/understanding-the-composite-design-pattern-a-comprehensive-guide-with-real-world-applications-4855

信頼度: 9/10(設計原則と実装経験に基づく共通認識)

7.3 Compositeの誤用パターン

要点:

誤用例1: 階層関係がないのにCompositeを使う

問題: 単なるオブジェクトのコレクションにCompositeパターンを適用
影響: 不要な複雑性、コードの可読性低下
代替: 単純な配列やハッシュ、またはイテレータパターン

誤用例2: 平坦な2階層にCompositeを使う

問題: 深い階層がないのにComposite/Leafの抽象化を導入
影響: 過剰な抽象化によるオーバーヘッド
代替: 継承やシンプルなクラス設計

誤用例3: すべてのオブジェクトをCompositeにする

問題: Leafが存在せず、すべてのノードがComposite
影響: 不自然な設計、パフォーマンス低下
対策: 末端ノードは明確にLeafとして定義

根拠:

Compositeパターンは階層構造に特化したパターンであり、適用範囲を誤ると逆効果
設計原則「YAGNI(You Aren’t Gonna Need It)」に従い、必要な場合にのみパターンを適用

出典:

Composite Design Pattern - GeeksforGeeks: https://www.geeksforgeeks.org/system-design/composite-method-software-design-pattern/

信頼度: 8/10(実装経験からの知見)

調査まとめ

主要な発見

GoF定義の明確性: Compositeパターンは、部分-全体階層をツリー構造で表現し、個別オブジェクトと複合オブジェクトを統一的に扱う構造パターンとして確立されている
SOLID原則との強い親和性: 特に開放閉鎖原則(OCP)と依存性逆転の原則(DIP)を自然にサポート。ただし、リスコフの置換原則(LSP)については実装方法によって違反の可能性あり
実世界での豊富な実装例: ファイルシステム、GUIコンポーネント、組織図など、多様な分野で実装されており、実用性が高い
Perl/Mooでの実装可能性: MooのMoo::Role、has、配列操作を活用することで、PerlでもCompositeパターンを簡潔に実装可能。CPANには実装例が少ないため、差別化の余地が大きい
他パターンとの組み合わせ: Iterator(ツリー走査)、Visitor(操作追加)、Flyweight(メモリ最適化)と自然に組み合わせられる
アンチパターンへの認識: 循環参照、過度な抽象化、不適切な適用場面など、明確なトレードオフと注意点が存在
競合記事の傾向: Java/C++/Pythonでの実装例が中心。Perl/Mooでの段階的な解説記事は希少
既存記事との連携: サイト内には既にPrototype、State、Factory Method、Decoratorなど複数のGoFパターン実装記事が存在。Compositeパターンを加えることで、構造パターンのカバレッジが向上

作成日: 2026年01月20日
担当エージェント: investigative-research
保存先: content/warehouse/composite-pattern.md

チェックリスト

各セクションに「要点」「根拠」「出典」「信頼度」が記載されているか
出典URLが有効であるか
信頼度の根拠が明確か(1-10の10段階評価)
仮定がある場合は明記されているか(該当する場合のみ)
内部リンク候補が調査されているか(grepでcontent/postを検索済み)
タグが英語小文字・ハイフン形式か
提案・次のステップ・記事構成案・テーマ提案が含まれていないか(調査ドキュメントは事実情報のみを記録)