Featured image of post

複数デザインパターンの組み合わせシリーズ 調査報告書

調査実施日

2026年1月22日

調査目的

「Perlで学ぶデザインパターンシリーズ」の新連載として、2種類以上のデザインパターンを組み合わせて使用する記事企画のための包括的な調査。

想定読者

  • Perl入学式卒業レベル（基礎文法とOOPの基礎を習得済み）
  • Moo を使った OOP に慣れている
  • 技術スタック: Perl v5.36以降、signatures・postfix dereference対応

1. 複数パターンの自然な組み合わせ例

1.1 Composite + Visitor パターン

要点

ファイルシステム、AST（抽象構文木）、GUI コンポーネントなど、ツリー構造データに対する操作の追加に最も頻繁に使われる組み合わせ。Compositeでツリー構造を表現し、Visitorで操作を外部化する。

詳細

  • Composite の役割: ファイル/フォルダ、式ノード、UIコンポーネントなど、葉（Leaf）と複合（Composite）を統一的に扱う
  • Visitor の役割: ツリーの走査・集計・変換・検証など、新しい操作を既存クラスを変更せずに追加できる
  • 実務例:
    • コンパイラ・インタプリタ: AST を Composite で構築し、Visitor で型チェック・最適化・コード生成を実施
    • グラフィックエディタ: 図形の階層構造を Composite で管理し、描画・変換・エクスポートを Visitor で実装
    • ファイルエクスプローラー: ファイル/フォルダツリーを Composite で扱い、サイズ計算・検索・レポート生成を Visitor で追加

なぜ組み合わせるのか

Composite 単体では操作を各ノードクラスに追加する必要があり、クラスが肥大化する。Visitor を組み合わせることで、開放閉鎖原則（OCP） を守りながら新しい操作を追加できる。

根拠

  • York University の講義資料では、Composite + Visitor の組み合わせを「最も強力なパターンコンビネーション」として紹介
  • 「Crafting Interpreters」や多数のコンパイラ設計書で標準的な手法として採用されている

出典

信頼度

10/10 - 学術・実務の両面で実証されている定番の組み合わせ

1.2 Bridge + Adapter パターン

要点

複数の外部API・レガシーシステムを統一インターフェースでラップしながら、抽象と実装を分離する。API統合・クロスプラットフォーム対応に有効。

詳細

  • Bridge の役割: 抽象（サービス層）と実装（APIクライアント）を分離し、独立に変更可能にする
  • Adapter の役割: 既存の/レガシーのAPIインターフェースを統一形式に変換する
  • 実務例:
    • 天気情報APIラッパー: 複数の天気API（OpenWeatherMap, WeatherStack, レガシーAPI）をBridgeで抽象化し、各APIごとにAdapterで統一インターフェースに適合
    • 決済ゲートウェイ: Stripe, PayPal, Square など異なる決済APIをAdapterで統一し、Bridgeで決済サービスと実装を分離
    • グラフィックス描画: DirectX/OpenGL/Vulkan などプラットフォーム依存の描画APIをAdapterでラップし、Bridgeで図形とレンダラーを分離

なぜ組み合わせるのか

Bridge 単体では既存APIの差異を吸収しきれない。Adapter を組み合わせることで、既存システムとの互換性を保ちながら柔軟な抽象化が実現できる。

根拠

  • Stack Overflow の議論では、Bridge と Adapter の違いを理解した上での組み合わせが推奨されている
  • 大規模なAPI統合プロジェクトでは、両パターンの組み合わせが標準的なアーキテクチャとして採用されている

出典

信頼度

9/10 - 実務での採用例が豊富だが、適用場面の判断には経験が必要

1.3 Mediator + Observer パターン

要点

GUI・イベント駆動システムにおいて、コンポーネント間の複雑な相互作用を中央集権的に管理しながら、変更通知を疎結合に実現する。

詳細

  • Mediator の役割: コンポーネント間の複雑な調整ロジックを一元管理（例：フォームのバリデーション、相互依存するフィールド制御）
  • Observer の役割: 個別コンポーネントの状態変化を通知する低レベルのイベント機構
  • 実務例:
    • フォームバリデーション: ドロップダウンの選択に応じて他のフィールドを有効化/無効化する処理を Mediator で集約し、各フィールドの変更通知は Observer で実現
    • チャットシステム: メッセージ配信ロジックを Mediator で管理し、ユーザーのオンライン/オフライン状態変化を Observer で通知
    • ゲームUI: プレイヤーのHP変化を Observer で検知し、Mediator が複数のUIコンポーネント（HPバー、警告ポップアップ、サウンド）を協調制御

なぜ組み合わせるのか

Observer 単体ではコンポーネント間の複雑な調整が散在する。Mediator を組み合わせることで、イベント通知は疎結合のまま、ビジネスロジックは集中管理できる。

根拠

  • JavaFX, React, Angular など主要GUIフレームワークで採用されている設計パターン
  • イベント駆動Webアプリケーションの学術論文でも推奨されている組み合わせ

出典

信頼度

10/10 - GUIフレームワークで実証されている定番パターン

1.4 Builder + Strategy パターン

要点

複雑なオブジェクトの**段階的な構築（Builder）**と、**処理アルゴリズムの切り替え（Strategy）**を組み合わせる。設定の柔軟性と実行時の振る舞い変更を両立。

詳細

  • Builder の役割: 複数のオプション・パラメータを持つオブジェクトを段階的に構築（例：サンドイッチの具材選択）
  • Strategy の役割: 構築後のオブジェクトの振る舞いを切り替え可能にする（例：調理方法の選択）
  • 実務例:
    • レポート生成: Builder でレポートの種類・期間・フィルター条件を設定し、Strategy で出力形式（PDF/Excel/HTML）を切り替え
    • ゲームキャラクター: Builder で外見・装備・ステータスを設定し、Strategy で戦闘スタイル（攻撃的/防御的/支援）を選択
    • HTTPリクエスト構築: Builder でヘッダー・ボディ・認証情報を設定し、Strategy でリトライ戦略・タイムアウト処理を切り替え

なぜ組み合わせるのか

Builder 単体では構築するオブジェクトの振る舞いが固定される。Strategy を組み合わせることで、構築時の柔軟性と実行時の動的な振る舞い変更が実現できる。

根拠

  • Stack Overflow で「Builder と Strategy の組み合わせは適切か」という質問に対し、複数の専門家が肯定的な回答
  • RESTful API クライアントライブラリで実装例が多数存在

出典

信頼度

9/10 - 実装例は豊富だが、過度に複雑になる可能性があるため注意が必要

1.5 State + Strategy パターン（+ Behavior Tree）

要点

ゲームAI・ワークフローエンジンなど、**状態遷移（State）とアルゴリズム切り替え（Strategy）**を組み合わせ、さらに階層的な意思決定（Behavior Tree）を追加することで、高度な振る舞いを実現。

詳細

  • State の役割: 高レベルのモード管理（例：アイドル/パトロール/戦闘/逃走）
  • Strategy の役割: 各状態内での具体的な行動パターン（例：近接攻撃/遠距離攻撃）
  • Behavior Tree の役割: 状態内の詳細な意思決定ロジックを階層的に表現
  • 実務例:
    • ゲーム敵AI: State で敵の状態（警戒/追跡/攻撃）を管理し、Strategy で攻撃パターンを切り替え、Behavior Tree で詳細な行動（カバーを探す、アイテムを拾う）を制御
    • ワークフローエンジン: State でタスクの状態（待機/実行中/完了/エラー）を管理し、Strategy で実行方法（並列/順次）を選択、Behavior Tree で条件分岐を表現

なぜ組み合わせるのか

State 単体では状態内の複雑な振る舞いが扱いにくく、Strategy 単体では状態遷移が管理できない。3つを組み合わせることで、スケーラブルで保守しやすい複雑なAIが構築できる。

根拠

  • Unreal Engine, Unity などのゲームエンジンで標準的なAI設計パターン
  • 「Game AI Pro」シリーズで詳細に解説されている

出典

信頼度

10/10 - ゲーム業界で実証済みのベストプラクティス

1.6 Factory + Singleton + Strategy（プラグインアーキテクチャ）

要点

拡張可能なシステム（プラグイン、モジュール化）において、オブジェクト生成（Factory）、グローバルアクセス（Singleton）、**アルゴリズム切り替え（Strategy）**を組み合わせる。

詳細

  • Factory の役割: プラグインやモジュールの動的な生成・登録
  • Singleton の役割: プラグインレジストリへのグローバルアクセス
  • Strategy の役割: プラグインが提供する異なる実装の切り替え
  • 実務例:
    • Webフレームワークのミドルウェア: Factory でミドルウェアを生成し、Singleton でミドルウェアチェーンを管理、Strategy で認証/ログ/キャッシュなどの処理を切り替え
    • チャットボット: Factory でプラグイン（天気情報/翻訳/計算）を生成し、Singleton でプラグインマネージャーを管理、Strategy でコマンド処理を実行

根拠

  • Django, Flask, Express.js などのWebフレームワークで採用されているアーキテクチャ
  • CPAN モジュールでも同様のパターンが多数存在

出典

信頼度

9/10 - 広く採用されているが、Singleton の使用には注意が必要

2. Perl/Mooでの実装例の有無

2.1 CPAN モジュールにおける複数パターン実装

要点

CPAN には約700のMooベースモジュールが存在し、多くが複数のデザインパターンを組み合わせている。

主要な事例

MooX::Role::Parameterized

  • パターン: Strategy + Template Method
  • 役割: パラメータ化されたロールでStrategy パターンを実現

MooX::Singleton

  • パターン: Singleton（Factory との組み合わせで使用されることが多い）
  • 役割: Moo クラスにシングルトン機能を追加

Web::Scraper

  • パターン: Builder + Strategy
  • 役割: CSS/XPathセレクタでスクレイピングルールを段階的に構築（Builder）、異なるパーサー戦略を切り替え（Strategy）
  • 出典: https://metacpan.org/pod/Web::Scraper

WWW::Mechanize

  • パターン: Facade + Command
  • 役割: HTTPリクエストの複雑な操作をシンプルなインターフェースで提供（Facade）、フォーム送信やリンククリックをコマンドとして実行（Command）
  • 出典: https://metacpan.org/pod/WWW::Mechanize

Mojo::UserAgent / Mojo::DOM

Perl固有の実装上の考慮点

1. Roleによるパターン実装

  • Moo::Role を活用することで、多重継承の問題を回避しながら複数パターンを組み合わせられる
  • 例: Composite パターンの Component を Role で定義し、Leaf と Composite が共通インターフェースを実装

2. サブルーチンリファレンスでのStrategy実装

  • Perl の第一級関数を活用し、Strategy をクラスではなくサブルーチンリファレンスとして実装できる
  • 軽量で柔軟な Strategy パターンが可能

3. postfix dereference の活用

  • Perl v5.20以降の postfix dereference（$obj->@*, $obj->%*）でコレクション操作が簡潔になる
  • Composite や Iterator パターンの実装が読みやすくなる

4. signaturesによる型安全性の向上

  • Perl v5.36 の signatures を使うことで、パターン実装時のメソッドシグネチャが明確になる
  • sub visit($self, $element) { ... } のように記述できる

出典

信頼度

9/10 - Moo での実装例は豊富だが、ドキュメント化が不十分な場合もある

3. 初心者向けに教えやすい組み合わせ

3.1 推奨組み合わせランキング

第1位: Composite + Iterator

理由:

  • 視覚化しやすい: ツリー構造（ファイルシステム、組織図、RPGインベントリ）は理解しやすい
  • 段階的な学習: まず Composite でツリーを作り、次に Iterator で走査するという明確な手順
  • 実用性: ファイル操作、ゲーム開発、データ構造処理など応用範囲が広い

学習効果:

  • 再帰的なデータ構造の理解
  • インターフェースの統一的な扱い方
  • 構造と操作の分離（開放閉鎖原則）

題材例:

  • テキストRPGのインベントリシステム（バッグの中にアイテムやさらに小さなバッグ）
  • Markdown ファイルの見出し構造を解析・整形するツール
  • ディレクトリツリーの可視化ツール

第2位: Strategy + Template Method

理由:

  • 比較学習: 似たパターンの違いを理解できる（いつStrategyを使い、いつTemplate Methodを使うか）
  • 実務的: データ処理パイプライン、バリデーション、フォーマット変換など頻出パターン
  • Perl らしさ: サブルーチンリファレンスを活用した軽量実装が可能

学習効果:

  • アルゴリズムの差し替え vs 処理の流れの固定化
  • 継承 vs 委譲の使い分け
  • 開放閉鎖原則の2つの実現方法

題材例:

  • ログ解析ツール（Template Method で解析フロー固定、Strategy で各ログ形式に対応）
  • データバリデーター（Template Method で検証フロー統一、Strategy で検証ルール切り替え）
  • テストデータジェネレーター（Template Method で生成手順固定、Strategy でデータ種別切り替え）

第3位: Builder + Factory

理由:

  • 生成パターンの基礎: オブジェクト生成の2大パターンを同時に学習
  • 明確な役割分担: Builder は複雑なオブジェクトの段階的構築、Factory は型の選択
  • 実装が明快: Perl/Moo で実装しやすい

学習効果:

  • オブジェクト生成の複雑さの隠蔽
  • インターフェースの流暢性（Fluent Interface）
  • 生成ロジックの集約

題材例:

  • HTTPリクエストビルダー（Builder で詳細設定、Factory で HTTP メソッド選択）
  • ゲームキャラクター生成システム（Builder でパラメータ設定、Factory でクラス/種族選択）
  • レポート生成ツール（Builder で内容構築、Factory で出力形式選択）

第4位: Observer + Command

理由:

  • イベント駆動の基礎: 現代的なプログラミングパラダイムの理解
  • 実装が簡潔: Perl のサブルーチンリファレンスで簡単に実装できる
  • 実用性: CLI ツール、自動化スクリプト、ワークフロー管理で頻出

学習効果:

  • 疎結合な設計
  • イベント駆動プログラミング
  • アクションのカプセル化

題材例:

  • ファイル監視ツール（Observer で変更検知、Command で実行するアクション）
  • タスクスケジューラー（Observer でトリガー検知、Command でタスク実行）
  • チャットボット（Observer でメッセージ受信、Command で応答処理）

第5位: Adapter + Proxy

理由:

  • 構造パターンの基礎: インターフェース変換とアクセス制御の理解
  • 実務頻出: API 連携、レガシーコードの統合で必須
  • 段階的学習: まず Adapter で基本を学び、次に Proxy で高度な制御を追加

学習効果:

  • インターフェースの適合化
  • アクセス制御とキャッシング
  • 既存コードを変更せずに機能追加

題材例:

  • 複数のクラウドストレージAPI統合（Adapter で統一I/F、Proxy でキャッシング）
  • レガシーデータベースへのアクセス（Adapter で新I/F提供、Proxy で接続プーリング）
  • API レート制限対応（Adapter で統一形式、Proxy でリクエスト制御）

3.2 避けるべき組み合わせ（初心者向けではない）

Visitor + Interpreter:

  • 両方とも抽象度が高く、初心者には理解が困難
  • 実務でも使用頻度が低い

Abstract Factory + Prototype + Singleton:

  • 生成パターン3つの組み合わせは過剰設計になりやすい
  • どのパターンがどの責務を持つか混乱しやすい

Mediator + Chain of Responsibility + Command:

  • 責務の分離が曖昧になりやすい
  • デバッグが困難

4. 面白い・変わった題材のアイデア

4.1 ゲーム・エンターテインメント系

テーマ1: テキストRPG 戦闘システム

使用パターン: State + Strategy + Command + Observer

概要:

  • State パターンで戦闘フェーズ管理（開始/プレイヤーターン/敵ターン/終了）
  • Strategy パターンで戦闘AI（攻撃的/防御的/ランダム）
  • Command パターンで行動のカプセル化（攻撃/防御/アイテム使用/逃走）
  • Observer パターンでイベント通知（HP変化、状態異常、レベルアップ）

友人に自慢できるポイント:

  • コマンドラインで動く本格的なRPG戦闘エンジン
  • AI の戦闘パターンを自作できる
  • 戦闘ログをリプレイ可能（Command パターンのundo/redo）

学習効果:

  • 複数パターンの協調動作
  • イベント駆動プログラミング
  • 状態管理とアルゴリズム切り替えの実践

テーマ2: マルコフ連鎖テキスト生成器 + プラグインシステム

使用パターン: Factory + Strategy + Decorator + Observer

概要:

  • Factory パターンでテキスト生成エンジン選択（マルコフ連鎖/n-gram/GPT風）
  • Strategy パターンで文章スタイル切り替え（丁寧語/砕けた口調/古文調）
  • Decorator パターンで後処理追加（絵文字挿入/敬語変換/校正）
  • Observer パターンで生成イベント通知（進捗表示、統計収集）

友人に自慢できるポイント:

  • Twitter bot や面白い文章生成ツールが作れる
  • プラグインで機能拡張が可能
  • 生成過程を可視化できる

学習効果:

  • プラグインアーキテクチャの設計
  • 自然言語処理の基礎
  • 機能の段階的な追加（Decorator）

テーマ3: ダンジョン自動生成器

使用パターン: Builder + Composite + Iterator + Template Method

概要:

  • Builder パターンで部屋の段階的構築（サイズ/形状/出口/アイテム/敵配置）
  • Composite パターンでダンジョン構造管理（エリア→部屋→オブジェクト）
  • Iterator パターンでダンジョン探索（深さ優先/幅優先）
  • Template Method パターンで生成アルゴリズム（洞窟風/城風/迷宮風）

友人に自慢できるポイント:

  • ローグライク風のダンジョンが自動生成される
  • ASCII アートまたは HTML/SVG で可視化
  • Twitterで生成結果をシェアできる

学習効果:

  • ゲームアルゴリズムの理解
  • 再帰的データ構造の操作
  • アルゴリズムの骨格と具体実装の分離

4.2 自動化・ハッキング系

テーマ4: Webスクレイピング＆分析パイプライン

使用パターン: Chain of Responsibility + Strategy + Observer + Proxy

概要:

  • Chain of Responsibility でスクレイピング処理チェーン（取得→解析→変換→保存）
  • Strategy パターンでパーサー切り替え（HTML/JSON/XML/CSV）
  • Observer パターンでスクレイピング進捗通知（成功/失敗/エラー）
  • Proxy パターンでアクセス制御（レート制限/キャッシング/リトライ）

友人に自慢できるポイント:

  • 複数サイトから自動でデータ収集
  • 価格監視、在庫チェック、ニュース集約などに応用可能
  • エラーハンドリングとリトライ機能で堅牢

学習効果:

  • HTTP通信とHTML解析
  • エラーハンドリングとリトライ戦略
  • 責任の連鎖パターン

テーマ5: Git リポジトリ解析ツール

使用パターン: Composite + Visitor + Strategy + Template Method

概要:

  • Composite パターンでリポジトリ構造管理（ディレクトリ→ファイル→コミット）
  • Visitor パターンで解析処理（コードメトリクス/変更頻度/著者統計）
  • Strategy パターンで解析手法切り替え（言語別/期間別/著者別）
  • Template Method パターンでレポート生成（Markdown/HTML/JSON）

友人に自慢できるポイント:

  • 自分のプロジェクトの統計をビジュアル化
  • 「誰が一番コミットしたか」などチーム分析
  • GitHub Pages で公開可能なレポート

学習効果:

  • Git の内部構造理解
  • データ分析とレポート生成
  • 複数の解析処理を拡張可能に保つ設計

テーマ6: ログ解析＆アラートシステム

使用パターン: Observer + Strategy + Command + State

概要:

  • Observer パターンでログファイル監視（リアルタイム/定期実行）
  • Strategy パターンでログパーサー切り替え（Apache/Nginx/アプリケーションログ）
  • Command パターンでアラートアクション（メール/Slack/SMS）
  • State パターンでアラート状態管理（正常/警告/危険/復旧済み）

友人に自慢できるポイント:

  • 自宅サーバーやVPSの監視システムが作れる
  • 異常検知で自動アラート
  • ダッシュボード機能で可視化

学習効果:

  • ファイル監視とイベント駆動
  • 状態遷移の管理
  • 実用的な監視システムの構築

4.3 データ分析・可視化系

テーマ7: 時系列データ可視化エンジン

使用パターン: Builder + Strategy + Decorator + Template Method

概要:

  • Builder パターンでグラフ設定の段階的構築（データ/軸/凡例/スタイル）
  • Strategy パターンでグラフ種別切り替え（折れ線/棒/散布図/ヒートマップ）
  • Decorator パターンでグラフ装飾（移動平均/トレンドライン/注釈）
  • Template Method パターンで出力形式（SVG/PNG/HTML/ASCII art）

友人に自慢できるポイント:

  • コマンドラインでグラフ生成
  • 株価、天気、アクセスログなど何でも可視化
  • ASCII art グラフならターミナルで完結

学習効果:

  • データ可視化の基礎
  • 柔軟な設定システムの設計
  • 装飾パターンによる機能追加

テーマ8: データパイプラインシミュレーター

使用パターン: Chain of Responsibility + Strategy + Observer + Command

概要:

  • Chain of Responsibility でETL処理チェーン（抽出→変換→検証→読込）
  • Strategy パターンでデータソース切り替え（CSV/JSON/Database/API）
  • Observer パターンで処理進捗とエラー通知
  • Command パターンでパイプライン操作（実行/停止/再開/ロールバック）

友人に自慢できるポイント:

  • データエンジニアリングの基礎が学べる
  • 実際のETLワークフローをシミュレート
  • エラー時のロールバック機能で堅牢性を実証

学習効果:

  • データパイプラインの設計
  • トランザクション処理の基礎
  • エラーハンドリングと回復処理

4.4 ユニーク・実験的系

テーマ9: ポモドーロタイマー with プラグイン

使用パターン: State + Strategy + Observer + Factory

概要:

  • State パターンで作業状態管理（作業中/休憩中/長休憩/一時停止）
  • Strategy パターンで通知方法切り替え（音/デスクトップ通知/Slack/メール）
  • Observer パターンでタイマーイベント通知（開始/終了/カウントダウン）
  • Factory パターンでプラグイン生成（統計/タスク管理/音楽再生）

友人に自慢できるポイント:

  • 自分専用のポモドーロタイマー
  • 作業ログを自動記録・分析
  • プラグインで拡張可能（Spotify連携、Toggl連携など）

学習効果:

  • 状態遷移と時間管理
  • プラグインアーキテクチャ
  • GUIまたはCLIでの実装

テーマ10: コード生成器ジェネレーター

使用パターン: Builder + Template Method + Factory + Visitor

概要:

  • Builder パターンでコードテンプレート構築
  • Template Method パターンで生成フロー固定
  • Factory パターンで言語別ジェネレーター選択
  • Visitor パターンでAST走査と変換

友人に自慢できるポイント:

  • 「コードを書くコードを書く」メタプログラミング
  • Perl/Python/JavaScript など複数言語対応
  • ボイラープレートコードを自動生成

学習効果:

  • メタプログラミングの理解
  • コンパイラ・インタプリタの基礎
  • 複数言語の構文理解

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

5.1 Mooでの実装パターン

ロール（Role）の活用

 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

# Composite パターンの Component をロールで定義
package Component {
    use Moo::Role;
    use feature 'signatures';
    
    requires 'display';
    requires 'add';
    requires 'remove';
}

# Leaf の実装
package Leaf {
    use Moo;
    use feature 'signatures';
    
    with 'Component';
    
    has name => (is => 'ro', required => 1);
    
    sub display($self) { say "Leaf: " . $self->name }
    sub add($self, $component) { die "Cannot add to leaf" }
    sub remove($self, $component) { die "Cannot remove from leaf" }
}

# Composite の実装
package Composite {
    use Moo;
    use feature 'signatures';
    
    with 'Component';
    
    has name => (is => 'ro', required => 1);
    has children => (is => 'ro', default => sub { [] });
    
    sub add($self, $component) {
        push $self->children->@*, $component;
    }
    
    sub remove($self, $component) {
        $self->children->@* = grep { $_ ne $component } $self->children->@*;
    }
    
    sub display($self) {
        say "Composite: " . $self->name;
        $_->display() for $self->children->@*;
    }
}

Strategy パターンのサブルーチンリファレンス実装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

package Calculator {
    use Moo;
    use feature 'signatures';
    
    has strategy => (is => 'rw', required => 1);
    
    sub calculate($self, $a, $b) {
        return $self->strategy->($a, $b);
    }
}

# 使用例
my $add = sub($a, $b) { $a + $b };
my $multiply = sub($a, $b) { $a * $b };

my $calc = Calculator->new(strategy => $add);
say $calc->calculate(3, 4);  # 7

$calc->strategy($multiply);
say $calc->calculate(3, 4);  # 12

Observer パターンの軽量実装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

package Subject {
    use Moo;
    use feature 'signatures';
    
    has observers => (is => 'ro', default => sub { [] });
    
    sub attach($self, $observer) {
        push $self->observers->@*, $observer;
    }
    
    sub notify($self, $event) {
        $_->($event) for $self->observers->@*;
    }
}

# 使用例
my $subject = Subject->new();
$subject->attach(sub($event) { say "Observer 1: $event" });
$subject->attach(sub($event) { say "Observer 2: $event" });
$subject->notify("Something happened!");

5.2 Perl v5.36 以降の機能活用

signatures の活用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

use v5.36;
use experimental 'signatures';

package Visitor {
    use Moo;
    
    sub visit_book($self, $book) {
        say "Visiting book: " . $book->title;
    }
    
    sub visit_magazine($self, $magazine) {
        say "Visiting magazine: " . $magazine->issue;
    }
}

postfix dereference の活用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

use v5.36;

package Composite {
    use Moo;
    
    has children => (is => 'ro', default => sub { [] });
    
    sub add($self, $child) {
        push $self->children->@*, $child;
    }
    
    sub display($self) {
        $_->display() for $self->children->@*;
    }
}

builtin 関数の活用（v5.36+）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

use v5.36;
use builtin qw(true false is_bool);

package State {
    use Moo;
    
    has is_active => (is => 'rw', default => sub { false });
    
    sub activate($self) {
        $self->is_active(true);
    }
}

5.3 CPAN モジュールとの連携

Type::Tiny による型チェック

1
2
3
4
5
6
7
8
9

use Types::Standard qw(Str Int ArrayRef);

package Item {
    use Moo;
    use Types::Standard qw(Str Int);
    
    has name => (is => 'ro', isa => Str, required => 1);
    has price => (is => 'ro', isa => Int, required => 1);
}

Path::Tiny でファイル操作（Composite パターンと相性良）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

use Path::Tiny;

sub build_file_tree($path) {
    return Leaf->new(name => $path->basename) if $path->is_file;
    
    my $composite = Composite->new(name => $path->basename);
    for my $child ($path->children) {
        $composite->add(build_file_tree($child));
    }
    return $composite;
}

6. 推奨する連載構成案

6.1 初心者向けシリーズ（全5回）

第1回: Composite + Iterator パターンでテキストRPGインベントリ

  • 難易度: ★★☆☆☆
  • 学習目標: ツリー構造、再帰、インターフェースの統一
  • 成果物: コマンドラインで動くインベントリ管理システム

第2回: Strategy + Template Method パターンでログ解析ツール

  • 難易度: ★★★☆☆
  • 学習目標: アルゴリズム切り替え、処理の流れの固定化
  • 成果物: 複数形式のログファイルを解析できるツール

第3回: Builder + Factory パターンでHTTPリクエストビルダー

  • 難易度: ★★★☆☆
  • 学習目標: オブジェクト生成の複雑さの隠蔽、流暢なインターフェース
  • 成果物: RESTful API クライアント

第4回: Observer + Command パターンでファイル監視ツール

  • 難易度: ★★★☆☆
  • 学習目標: イベント駆動、アクションのカプセル化
  • 成果物: ファイル変更を監視して任意のコマンドを実行するツール

第5回: 総合演習 - 複数パターンを組み合わせたWebスクレイパー

  • 難易度: ★★★★☆
  • 学習目標: パターンの協調動作、実務的なアプリケーション設計
  • 成果物: プラグイン機能付きWebスクレイピングフレームワーク

6.2 中級者向けシリーズ（全3回）

第1回: Composite + Visitor パターンでAST解析器

  • 難易度: ★★★★☆
  • 学習目標: コンパイラ設計の基礎、Double Dispatch
  • 成果物: 簡易プログラミング言語のパーサーと評価器

第2回: Bridge + Adapter パターンで複数API統合

  • 難易度: ★★★★☆
  • 学習目標: 抽象と実装の分離、既存システムの統合
  • 成果物: 複数のクラウドストレージを統一I/Fで操作できるツール

第3回: State + Strategy + Observer パターンでゲームAI

  • 難易度: ★★★★★
  • 学習目標: 複雑な状態管理、AIアルゴリズム
  • 成果物: テキストRPGの敵AIシステム

7. 調査結果まとめと推奨事項

7.1 最も推奨する組み合わせ（初心者向け）

第1候補: Composite + Iterator

  • 理由: 視覚化しやすく、実用的で、段階的に学習できる
  • 題材: テキストRPGインベントリ、ファイルツリー操作、組織図管理
  • 信頼度: 10/10

第2候補: Strategy + Template Method

  • 理由: 似たパターンの比較学習、実務頻出、Perlらしい実装
  • 題材: ログ解析、データバリデーション、レポート生成
  • 信頼度: 10/10

第3候補: Builder + Factory

  • 理由: 生成パターンの基礎、明確な役割分担、流暢なインターフェース
  • 題材: HTTPリクエストビルダー、ゲームキャラクター生成、設定管理
  • 信頼度: 9/10

7.2 最も面白い題材（友人に自慢できる）

第1候補: テキストRPG戦闘システム（State + Strategy + Command + Observer）

  • ゲーム性があり、視覚的に面白い
  • 複数パターンの協調動作を実感できる
  • 拡張性が高く、自分でカスタマイズできる

第2候補: Webスクレイピング＆分析パイプライン（Chain of Responsibility + Strategy + Observer + Proxy）

  • 実用的で即効性がある
  • 価格監視、在庫チェックなど応用範囲が広い
  • 自動化の醍醐味を味わえる

第3候補: Git リポジトリ解析ツール（Composite + Visitor + Strategy + Template Method）

  • 自分のプロジェクトを分析できる
  • ビジュアル化されたレポートが作れる
  • チーム開発で実用性がある

7.3 実装上の重要ポイント

  1. Moo::Role を積極的に活用: 多重継承を避け、柔軟なパターン実装を実現
  2. サブルーチンリファレンスで Strategy を実装: 軽量で Perl らしい実装
  3. postfix dereference で可読性向上: 配列・ハッシュ操作が簡潔になる
  4. signatures で型安全性向上: メソッドシグネチャが明確になる
  5. Type::Tiny で型チェック: より堅牢なコードを書ける

7.4 連載における注意点

  1. 段階的な難易度設定: 1パターンずつ理解→組み合わせの順で進める
  2. 実務的な題材選択: 「これ、仕事で使えそう」と思わせる内容
  3. 視覚化の重視: ASCII art、図表、動作デモで理解を促進
  4. 完動するコード: 読者がすぐに試せる完全なサンプルコード
  5. 拡張課題の提示: 「ここをこう変えると○○になる」という発展例

8. 参考文献・出典リスト

8.1 書籍

  1. Gang of Four (1994). “Design Patterns: Elements of Reusable Object-Oriented Software”
  2. “Head First Design Patterns” - O’Reilly Media
  3. “Design Patterns in Modern Perl” by Mohammad Sajid Anwar (2024)

8.2 オンライン資料

デザインパターン一般

パターン組み合わせ

Perl 実装

ゲームAI

データエンジニアリング

8.3 CPAN モジュール

9. 調査結論

9.1 連載の実現可能性

結論: 非常に高い（9/10）

  • CPAN に豊富な実装例が存在
  • Moo での実装が簡潔で初心者にも理解しやすい
  • 実務的な題材が多数存在
  • 既存シリーズとの差別化が可能

9.2 推奨する第1弾テーマ

「Composite + Iterator パターンでテキストRPGインベントリシステムを作ろう」

理由:

  1. 視覚的に理解しやすい（バッグの中にアイテム、さらにバッグ）
  2. ゲーム性があり、読者の興味を引きやすい
  3. 段階的な学習が可能（まず Composite、次に Iterator）
  4. 実用性が高い（ファイルシステム、組織図など応用範囲が広い）
  5. Perl/Moo での実装が簡潔

想定される学習効果:

  • 再帰的なデータ構造の理解
  • インターフェースの統一的な扱い
  • 構造と操作の分離（開放閉鎖原則）
  • ツリー構造の走査アルゴリズム

成果物イメージ:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

あなたのインベントリ:
├─ 回復ポーション (x3)
├─ ロングソード
├─ 革のバッグ
│  ├─ 鍵束
│  └─ 金貨 (x50)
└─ 冒険者のバックパック
   ├─ 魔法の巻物
   ├─ 小さなポーチ
   │  ├─ 宝石 (x2)
   │  └─ 古いコイン
   └─ 松明 (x5)

総アイテム数: 12
総重量: 15.3kg

9.3 今後の調査課題

  1. 性能測定: 各パターン組み合わせの性能特性（メモリ使用量、実行速度）
  2. テストコード作成: Test2 を使った効果的なテスト戦略
  3. モダンPerl機能の活用: v5.38 以降の新機能（class、field）との統合
  4. CPANモジュール化: 実装したコードのCPAN公開手順

調査完了日時

2026年1月22日

調査者コメント

複数デザインパターンの組み合わせは、実務でも頻繁に使用される重要なスキルです。本調査では、初心者にも理解しやすく、かつ実用的な組み合わせを多数発見できました。

特に「Composite + Iterator」は、視覚的に理解しやすく、実装も簡潔で、応用範囲も広いため、シリーズ第1弾として最適です。ゲーム開発という題材は、技術的な学習だけでなく、楽しみながら学べる点で優れています。

Perl v5.36 以降の機能（signatures、postfix dereference）と Moo を組み合わせることで、モダンで読みやすいコードが書けることも確認できました。

今後の連載では、各パターンの理論的な理解だけでなく、実際に動くコードを提供し、読者が自分で拡張できるような構成を目指すべきでしょう。

End of Report

comments powered by Disqus
© 2000 - 2026 設計パターンを疑え
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。