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

調査目的

Decoratorパターン（デコレーターパターン）に関する包括的な調査を行い、シリーズ記事作成の基盤となる情報を収集する。

• 調査対象: GoF定義、構造、利用シーン、メリット/デメリット、SOLID原則との関係、Perl/Moo実装
• 想定読者: Perl/Mooでデザインパターンを学習したいエンジニア
• 調査実施日: 2026年01月17日

1. 概要

1.1 GoFによる定義と意図（Intent）

要点:

• 定義: オブジェクトに動的に追加の責任（responsibilities）を付加する。Decoratorは、サブクラス化よりも柔軟な機能拡張の代替手段を提供する
• 意図: オブジェクトを変更せずに、実行時に動的かつ透過的に責任を追加する
• 分類: 構造パターン（Structural Pattern）
• 別名: Wrapper（ラッパー）

根拠:

• Gang of Four（GoF）の『Design Patterns: Elements of Reusable Object-Oriented Software』における正式定義
• 開放閉鎖原則（OCP）をサポート: クラスは拡張に対して開いているが、変更に対して閉じている
• 他のオブジェクトに影響を与えずに、個々のオブジェクトに対して責任を追加できる

出典:

• Understanding the Decorator Pattern: GOF Design Pattern Explained with …: https://www.codegenes.net/blog/understand-the-decorator-pattern-with-a-real-world-example/
• Decorator Pattern | Structural Design Patterns | Object-Oriented …: https://softwarepatternslexicon.com/object-oriented/structural-design-patterns/decorator-pattern/
• Decorator Design Pattern - GeeksforGeeks: https://www.geeksforgeeks.org/system-design/decorator-pattern/

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

1.2 パターンの構造（Structure）

要点:

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

構造図（テキスト表現）:

1
2
3
4
5
6
7

Component
   |
   +-- ConcreteComponent
   |
   +-- Decorator (抽象クラス、Componentへの参照を保持)
         |
         +-- ConcreteDecorator (追加機能を実装)

根拠:

• GoF書籍のクラス図とパターン説明に基づく
• Component、ConcreteComponent、Decorator、ConcreteDecoratorはGoF標準の参加者（Participants）
• Decoratorは委譲（delegation）とコンポジション（composition）を利用する

出典:

• Decorator Pattern: Structure and Participants: https://www.systemoverflow.com/learn/structural-patterns/decorator-pattern/decorator-pattern-structure-and-participants
• Introduction To Decorator Pattern - Cloudaffle: https://cloudaffle.com/series/structural-design-patterns/decorator-pattern/
• Decorator Design Pattern - Rookie Nerd: https://rookienerd.com/tutorial/design-pattern/decorator-design-pattern

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

2. 用途

2.1 具体的な利用シーン

要点:

根拠:

• Java I/Oは教科書的なDecorator実装として広く知られ、InputStream/OutputStreamがComponent、各種ストリームがConcreteDecoratorの役割
• Webフレームワークにおけるミドルウェアパターンは、リクエスト処理パイプラインに動的に機能を追加するDecoratorの応用
• React HOCは関数型プログラミングのhigher-order function概念とDecoratorパターンの融合

出典:

• Enhancing Flexibility with Decorator Pattern: Use Cases and Examples: https://softwarepatternslexicon.com/java/structural-patterns/decorator-pattern/use-cases-and-examples/
• The Decorator Pattern in Java I/O Streams: Decorating … - Moments Log: https://www.momentslog.com/development/design-pattern/the-decorator-pattern-in-java-i-o-streams-decorating-input-output-streams-with-additional-functionality
• Decorator Pattern in Java with Real-World Examples: https://www.javaguides.net/2025/06/decorator-pattern-in-java.html
• React HOC Pattern: https://www.patterns.dev/react/hoc-pattern/
• Understanding Higher Order Components in React: A Comprehensive Guide: https://dev.to/bholu_tiwari/understanding-higher-order-components-in-react-a-comprehensive-guide-f2b

信頼度: 9/10（実装例が多数確認できる実績あるユースケース。ただし、フレームワークによって実装詳細は異なる）

3. サンプルコード

3.1 Perl/Mooでの基本実装例

要点:

Perl/Mooでは、hasでコンポーネント参照を保持し、around修飾子で既存メソッドをラップする手法が有効。 Moo::Roleを用いたRole合成により、複数のDecorator機能を動的に組み込むことも可能。

基本的なDecorator実装（Moo + around修飾子）:

 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
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

# 言語: perl
# バージョン: 5.36以上
# 依存: Moo（cpanm Mooでインストール）

# Component（インターフェース）
package Component;
use v5.36;
use Moo::Role;

requires 'operation';

1;

# ConcreteComponent（具象コンポーネント）
package ConcreteComponent;
use v5.36;
use Moo;

with 'Component';

sub operation ($self) {
    return "Base operation";
}

1;

# Decorator（基底デコレータ）
package Decorator;
use v5.36;
use Moo;

with 'Component';

has component => (
    is       => 'ro',
    does     => 'Component',
    required => 1,
);

sub operation ($self) {
    return $self->component->operation;
}

1;

# ConcreteDecoratorA（具象デコレータ）
package ConcreteDecoratorA;
use v5.36;
use Moo;

extends 'Decorator';

sub operation ($self) {
    my $base = $self->component->operation;
    return "[DecoratorA: $base]";
}

1;

# ConcreteDecoratorB（具象デコレータ）
package ConcreteDecoratorB;
use v5.36;
use Moo;

extends 'Decorator';

sub operation ($self) {
    my $base = $self->component->operation;
    return "[DecoratorB: $base]";
}

1;

# 使用例
use ConcreteComponent;
use ConcreteDecoratorA;
use ConcreteDecoratorB;

my $component = ConcreteComponent->new;
my $decorated = ConcreteDecoratorA->new(component => $component);
my $double_decorated = ConcreteDecoratorB->new(component => $decorated);

say $double_decorated->operation;
# 出力: [DecoratorB: [DecoratorA: Base operation]]

Roleベースのアプローチ（around修飾子使用）:

 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

# 言語: perl
# バージョン: 5.36以上
# 依存: Moo（cpanm Mooでインストール）

# 基本クラス
package Printer;
use v5.36;
use Moo;

sub print_message ($self, $msg) {
    say "Message: $msg";
}

1;

# ログ機能を追加するRole（Decorator的役割）
package Role::Logger;
use v5.36;
use Moo::Role;

around print_message => sub ($orig, $self, @args) {
    say "[LOG] Calling print_message with: @args";
    $self->$orig(@args);   # 元のメソッド呼び出し
    say "[LOG] Finished print_message";
};

1;

# Roleを組み込んだクラス
package LoggingPrinter;
use v5.36;
use Moo;

extends 'Printer';
with 'Role::Logger';

1;

# 使用例
use LoggingPrinter;

my $printer = LoggingPrinter->new;
$printer->print_message('Hello, Decorator!');
# 出力:
# [LOG] Calling print_message with: Hello, Decorator!
# Message: Hello, Decorator!
# [LOG] Finished print_message

根拠:

• Mooのhas属性でComponentへの参照を保持し、委譲パターンを実現
• around修飾子は既存メソッドの前後に処理を挿入する機能で、Decorator的な動作を簡潔に実装可能
• Moo::Roleを用いることで、複数のDecorator機能をRoleとして定義し、動的に合成できる
• CPANにはMooseX::Traits（実行時Role合成）などDecoratorパターンを支援するモジュールも存在

出典:

• Moo - Minimalist Object Orientation (with Moose compatibility): https://metacpan.org/pod/Moo
• Moo::Role - Minimal Object Orientation support for Roles: https://metacpan.org/pod/Moo::Role
• OOP with Moo - Perl Maven: https://perlmaven.com/oop-with-moo
• Moose - A postmodern object system for Perl 5: https://metacpan.org/pod/Moose

信頼度: 9/10（Moo公式ドキュメントと実装例に基づく。ただし、動的なDecorator追加には追加の工夫が必要な場合がある）

3.2 CPAN上の関連モジュール

要点:

根拠:

• MooseとMooはPerlの主流OOシステムで、GoF Decoratorパターンの実装に必要な委譲、合成、Roleをサポート
• handlesオプションを使うことで、Componentへのメソッド委譲を宣言的に記述可能
• MooseX名前空間には多数の拡張モジュールが存在し、Decorator実装を支援

出典:

• MetaCPAN MooseX検索: https://metacpan.org/search?q=MooseX%3A%3A
• MetaCPAN MooX検索: https://metacpan.org/search?q=MooX%3A%3A
• Moose公式ドキュメント: https://metacpan.org/pod/Moose
• Role::Tiny: https://metacpan.org/pod/Role::Tiny

信頼度: 8/10（CPANの検索結果と各モジュールドキュメントに基づく。ただし、Decorator専用モジュールではないため、実装は開発者次第）

4. 利点・欠点

4.1 メリット

要点:

根拠:

• Decoratorパターンはコンポジションを用いるため、継承の制約（静的、組み合わせ爆発）を回避
• SOLID原則のうち、特にOCP（拡張に開き、変更に閉じる）とSRP（単一責任）を強く支援
• 各Decoratorは明確に責任が分離され、テストや保守が容易

出典:

• Decorator Design Pattern - GeeksforGeeks: https://www.geeksforgeeks.org/system-design/decorator-pattern/
• Decorator vs. Inheritance: https://softwarepatternslexicon.com/java/structural-patterns/decorator-pattern/decorator-vs-inheritance/
• Understanding the Decorator Pattern: GOF Design Pattern Explained: https://www.codegenes.net/blog/understand-the-decorator-pattern-with-a-real-world-example/
• Open-Closed Principle – SOLID Architecture Concept Explained: https://www.freecodecamp.org/news/open-closed-principle-solid-architecture-concept-explained/

信頼度: 10/10（広く認知されたDecoratorパターンの利点であり、複数の権威ある情報源で一致）

4.2 デメリット

要点:

根拠:

• Decoratorパターンは柔軟性と引き換えに、間接層の増加とクラス数増大を伴う
• 複数Decoratorの積み重ねにより、どのDecoratorがどの機能を追加したか追跡が困難になる
• 順序依存性は特にミドルウェアパターンで顕著（認証→ロギング vs ロギング→認証で結果が異なる）

出典:

• Criticism and Caveats Of The Decorator Pattern - Cloudaffle: https://cloudaffle.com/series/behavioral-design-patterns/decorator-pattern-criticism/
• Decorator Pattern: Trade-offs and When NOT to Use: https://www.systemoverflow.com/learn/structural-patterns/decorator-pattern/decorator-pattern-trade-offs-and-when-not-to-use
• Decorator – A Structural Design Pattern - springcavaj: https://springcavaj.com/decorator/
• What are the pros and cons of the decorator pattern?: https://stackoverflow.com/questions/14526518/what-are-the-pros-and-cons-of-the-decorator-pattern

信頼度: 9/10（複数の信頼できる技術文献で指摘されているデメリット。実装・運用経験からの知見）

5. SOLID原則との関係

5.1 開放閉鎖原則（Open/Closed Principle: OCP）との関係

要点:

• OCP定義: ソフトウェアエンティティ（クラス、モジュール、関数等）は、拡張に対して開いているが、変更に対して閉じているべき
• Decoratorとの関係: DecoratorパターンはOCPの教科書的実装例
• 既存のConcreteComponentを一切変更せずに、新しいDecoratorクラスを追加することで機能拡張を実現
• 新機能は新しいDecoratorとして「拡張」され、既存コードは「変更」されない

具体例:

Coffeeクラスに対して、ミルク、砂糖、ホイップクリームなどのオプションを追加する場合：

• 継承アプローチ: CoffeeWithMilk, CoffeeWithSugar, CoffeeWithMilkAndSugar, …とサブクラスが爆発
• Decoratorアプローチ: MilkDecorator, SugarDecorator, WhipDecoratorを定義し、任意に組み合わせ。Coffeeクラスは不変

根拠:

• OCP違反の典型例は、新機能のたびに既存クラスを修正すること
• Decoratorは新しい責任を追加する際に、既存コードを変更せず新しいクラスを作成するだけで対応
• GoF書籍でもDecoratorパターンがOCPをサポートすることが明示されている

出典:

• Open-Closed Principle – SOLID Architecture Concept Explained: https://www.freecodecamp.org/news/open-closed-principle-solid-architecture-concept-explained/
• Patterns in Practice: The Open Closed Principle - Microsoft: https://learn.microsoft.com/en-us/archive/msdn-magazine/2008/june/patterns-in-practice-the-open-closed-principle
• SOLID Design Principles and Design Patterns with Examples: https://dev.to/burakboduroglu/solid-design-principles-and-design-patterns-crash-course-2d1c

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

5.2 単一責任原則（Single Responsibility Principle: SRP）との関係

要点:

• SRP定義: クラスは変更する理由を1つだけ持つべき（単一の責任のみを持つ）
• Decoratorとの関係: 各Decoratorは単一の追加責任のみを持つ
• 機能をDecoratorに分離することで、ConcreteComponentは本来の責任に集中
• ロギング、認証、キャッシュなどの横断的関心事を個別のDecoratorクラスに分離

具体例:

Notifierクラスがメッセージ送信を担当する場合：

• SRP違反例: Notifierクラス内にログ記録、認証チェック、送信履歴保存などを全て実装
• Decorator適用: LoggingDecorator, AuthDecorator, HistoryDecoratorとして分離。Notifierは送信のみに責任を持つ

根拠:

• 複数の責任を1つのクラスに詰め込むと、変更理由が複数となり、保守性・テスト容易性が低下
• Decoratorパターンは責任を明確に分離するため、SRP遵守に貢献
• 各Decoratorは独立してテスト可能で、再利用性が高い

出典:

• Single Responsibility in SOLID Design Principle - GeeksforGeeks: https://www.geeksforgeeks.org/system-design/single-responsibility-in-solid-design-principle/
• SOLID Design Principles: The Single Responsibility Explained - Stackify: https://stackify.com/solid-design-principles/
• A Solid Guide to SOLID Principles - Baeldung: https://www.baeldung.com/solid-principles

信頼度: 10/10（SRPとDecoratorの関係は明確で、複数の教育的リソースで説明されている）

6. 関連トピックとの比較

6.1 Pythonデコレータとの違い

要点:

根拠:

• Pythonの@decoratorは、関数を受け取り関数を返す高階関数（higher-order function）であり、定義時に適用される
• GoF Decoratorは、オブジェクトを受け取りラップした新しいオブジェクトを返すパターンで、実行時に適用される
• 名前の類似性により混同されやすいが、概念的には異なる
• Pythonデコレータでもクラスベースデコレータを用いてGoF Decoratorパターンを実装することは可能

出典:

• What is the difference between Python decorators and the decorator pattern?: https://stackoverflow.com/questions/8328824/what-is-the-difference-between-python-decorators-and-the-decorator-pattern
• The Decorator Pattern - python-patterns.guide: https://python-patterns.guide/gang-of-four/decorator-pattern/
• Understanding the Decorator Pattern: GOF Design Pattern Explained: https://www.codegenes.net/blog/understand-the-decorator-pattern-with-a-real-world-example/

信頼度: 9/10（Pythonコミュニティと設計パターンコミュニティで広く議論されている区別）

6.2 React Higher-Order Components (HOC)との関係

要点:

• React HOCは、コンポーネント（関数またはクラス）を受け取り、拡張されたコンポーネントを返す関数
• HOCはDecoratorパターンの関数型プログラミング版と見なせる
• 元のコンポーネントを変更せずに、新しい機能（認証、データフェッチ、ローディング表示など）を追加
• 高階関数（higher-order function）の概念に基づき、Decoratorパターンの意図を関数型で実現

具体例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

const withAuth = (WrappedComponent) => {
  return function EnhancedComponent(props) {
    if (!isAuthenticated()) {
      return <Redirect to="/login" />;
    }
    return <WrappedComponent {...props} />;
  };
};

const ProtectedPage = withAuth(MyPage);

根拠:

• HOCは元のコンポーネントをラップし、追加の振る舞いを注入する点でDecoratorパターンと一致
• Reactコミュニティでは、HOCをDecoratorパターンの実装として説明する文献が多い
• ただし、現在ではReact Hooksが主流となり、HOCの使用頻度は減少傾向

出典:

• HOC Pattern - patterns.dev: https://www.patterns.dev/react/hoc-pattern/
• Understanding Higher Order Components in React: A Comprehensive Guide: https://dev.to/bholu_tiwari/understanding-higher-order-components-in-react-a-comprehensive-guide-f2b
• React JS HOC vs Decorator: What’s the Difference?: https://www.w3reference.com/blog/react-js-what-is-the-difference-betwen-hoc-and-decorator/

信頼度: 9/10（Reactコミュニティでの共通理解。ただし、Hooks導入以降の位置づけは変化している）

7. 関連記事・内部リンク

7.1 関連する既存記事

調査方法:

• /home/runner/work/www.nqou.net/www.nqou.net/content/post 配下を grep で検索
• 検索キーワード: デザインパターン, design.pattern, Decorator, Moo, SOLID, OOP, 開放閉鎖

信頼度: 10/10（サイト内記事の直接確認）

調査まとめ

主要な発見

1. GoF定義の明確性: Decoratorパターンは、動的な責任追加を目的とした構造パターンであり、継承に代わる柔軟な拡張手段として確立されている

2. SOLID原則との強い親和性: 特に開放閉鎖原則（OCP）と単一責任原則（SRP）の実践において、Decoratorパターンは理想的な実装モデルを提供する

3. 実世界での豊富な実装例: Java I/Oストリーム、Webミドルウェア、React HOCなど、多様な分野でDecoratorパターンが実装されており、実用性が高い

4. Perl/Mooでの実装可能性: Mooのhas、around修飾子、Moo::Roleを活用することで、PerlでもDecoratorパターンを簡潔に実装可能。CPANにはMooseX::Traitsなど支援モジュールも存在

5. デメリットへの認識: 多数の小クラス生成、デバッグ複雑化、順序依存性など、Decoratorパターンには明確なトレードオフが存在。適用場面の見極めが重要

6. 用語の混同に注意: Pythonデコレータ、React HOC、GoF Decoratorパターンは関連するが異なる概念。文脈に応じた正確な理解が必要

7. 既存記事との連携: サイト内には既にPrototype、Factory Method、State、Observerなど複数のGoFパターン実装記事が存在。Decoratorパターンを加えることで、デザインパターンのカバレッジが向上

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

チェックリスト

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