Singleton × Flyweight × Proxy パターン組み合わせ調査ドキュメント

調査概要

調査目的: 「デザインパターン学習シリーズ」読了者で、まだパターンが使いこなせない読者向けの実践復習シリーズ作成
調査実施日: 2026年1月30日
技術スタック: Perl v5.36以降（signatures、postfix dereference対応）、Moo
想定読者: デザインパターン学習シリーズを一通り読了したが、まだ自力で使いこなせない人
難易度評価: 3.5/5（3パターンの連携が必要だが、段階的に学習可能）

1. 各パターンの復習

1.1 Singleton パターン

要点:

GoF「生成パターン」の1つ
クラスのインスタンスを1つだけに制限し、グローバルアクセスポイントを提供
設定管理、ロガー、データベース接続プールなどで使用

Mooでの実装:

1
2
3
4
5
package ConfigManager;
use Moo;
use MooX::Singleton;  # Singletonを実現

has config => (is => 'ro', default => sub { {} });

または、Perl v5.36の state 変数を使用:

1
2
3
4
5
6
7
8
package ConfigManager;
use v5.36;
use Moo;

sub instance ($class) {
    state $instance = $class->new;
    return $instance;
}

既存シリーズでの題材: 設定ファイルマネージャー（全8回）

信頼度: 9/10

1.2 Flyweight パターン

要点:

GoF「構造パターン」の1つ
大量の類似オブジェクトを効率的にサポートするため、共通部分（内部状態）を共有
内部状態（Intrinsic State）と外部状態（Extrinsic State）の分離が核心

Mooでの実装:

1
2
3
4
5
6
7
8
9
package GlyphFactory;
use v5.36;
use Moo;

has _cache => (is => 'ro', default => sub { {} });

sub get_glyph ($self, $char) {
    return $self->_cache->{$char} //= Glyph->new(char => $char);
}

既存シリーズでの題材: 弾幕シューティング（全6回）

信頼度: 9/10

1.3 Proxy パターン

要点:

GoF「構造パターン」の1つ
実体（RealSubject）の代理（Proxy）を介してアクセスを制御
遅延初期化、アクセス制御、キャッシュ、ログなどの追加処理を挟める

代表的なProxyの種類:

種類	説明	典型例
Virtual Proxy	高コストな生成を遅延させる	画像・大きなデータの遅延読み込み
Protection Proxy	認可やアクセス制御を追加	管理者専用APIのガード
Caching Proxy	取得結果を保持して高速化	APIレスポンスのメモ化

Mooでの実装:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
package ImageProxy;
use v5.36;
use Moo;

has _real_image => (is => 'ro', lazy => 1, builder => '_load_image');

sub display ($self) {
    return $self->_real_image->display;
}

sub _load_image ($self) {
    return RealImage->new(path => $self->path);
}

既存シリーズでの題材:

ブルートフォース攻撃シミュレータ（全5回）
ゴーストギャラリー・ビューワ（全5回）

信頼度: 9/10

2. 3パターンの組み合わせ

2.1 組み合わせの必然性

3パターンが自然に連携するシナリオ:

パターン	役割	解決する問題
Singleton	グローバル設定・ファクトリの一元管理	設定の重複・不整合を防ぐ
Flyweight	大量オブジェクトのメモリ効率化	メモリ使用量の爆発を防ぐ
Proxy	アクセス制御・キャッシュ・遅延ロード	重い処理の最適化

2.2 相互作用パターン

1
2
3
4
5
6
7
Singleton (設定管理)
    ↓
Flyweight Factory (オブジェクト共有)
    ↓
Proxy (アクセス制御/キャッシュ)
    ↓
Real Object

典型的な連携:

Singletonが全体設定とFlyweight Factoryを管理
Flyweight FactoryがProxyを介してオブジェクトを提供
Proxyがキャッシュ/遅延ロード/アクセス制御を実装

3. 題材候補の調査

3.1 候補1: ASCIIアート・フォントレンダラー

概要: ASCIIアートフォント（FIGletスタイル）をレンダリングするツール

3パターンの役割:

パターン	役割	具体例
Singleton	フォント設定マネージャー	フォントパス、デフォルト設定を一元管理
Flyweight	文字グリフの共有	‘A’のグリフを複数箇所で再利用
Proxy	フォントファイルの遅延ロード	使用する文字だけロード

USP:

視覚的な出力で成果がわかりやすい
友人に「俺のASCIIアートジェネレーター見てよ」と自慢できる
FIGletは実在するツールで実用性がある

メリット:

デバッグしやすい（出力が目に見える）
段階的に学習できる
Perl入学式卒業レベルでも理解しやすい

デメリット:

実務での直接利用は限定的
フォントデータの準備が必要

3.2 候補2: タイルベース・マップエディタ

概要: ゲームマップのタイルを配置・表示するエディタ

3パターンの役割:

パターン	役割	具体例
Singleton	マップ設定マネージャー	タイルサイズ、マップサイズを一元管理
Flyweight	タイルオブジェクトの共有	草・水・壁タイルを再利用
Proxy	テクスチャの遅延ロード	表示領域のタイルだけロード

USP:

ゲーム性があり楽しい
完成したマップを見せて自慢できる
ローグライク/RPGへの応用イメージが湧く

メリット:

ゲーム系は学習モチベーションが高い
既存のダンジョン系とは異なる（配置＋編集に焦点）

デメリット:

やや複雑になりやすい
既存シリーズ（ダンジョンマスター等）と近い印象

3.3 候補3: 絵文字パレット・ジェネレーター

概要: Unicodeの絵文字を効率的に検索・表示・カスタマイズするツール

3パターンの役割:

パターン	役割	具体例
Singleton	絵文字データベース管理	Unicode絵文字マスターデータを一元管理
Flyweight	絵文字メタデータの共有	カテゴリ・タグ情報を共有
Proxy	絵文字データの遅延ロード	表示するカテゴリだけロード

USP:

実用的（チャットやドキュメントで使える）
Unicode知識も身につく
「俺専用の絵文字辞書を作った」と自慢できる

メリット:

モダンで実用的
データ量が多くFlyweightの効果が実感しやすい

デメリット:

絵文字処理はPerlでやや複雑
CLI表示に工夫が必要

4. 推奨題材

推奨: 候補1「ASCIIアート・フォントレンダラー」

推奨理由:

視覚的フィードバック: 出力結果が目に見え、学習効果を実感しやすい
段階的学習: Singleton→Flyweight→Proxyと自然に導入できる
デバッグ容易性: 問題の原因が特定しやすい
自慢しやすさ: 「俺のASCIIアートジェネレーター」は見た目のインパクトが強い
実在ツール: FIGletという実在ツールのミニ版という位置づけ

5. 既存シリーズとの差別化

5.1 使用済み題材（避けるべき）

シリーズ	題材	パターン
設定ファイルマネージャー	設定管理	Singleton
弾幕シューティング	ゲーム	Flyweight
ブルートフォース攻撃シミュレータ	セキュリティ	Proxy
ゴーストギャラリー・ビューワ	画像ギャラリー	Proxy
ダンジョン自動生成器	ゲーム	複数パターン
テキストRPG戦闘エンジン	ゲーム	複数パターン
ログ解析パイプライン	ログ処理	Decorator
天気情報ツール	API連携	Adapter
API統合パターン	API連携	Facade+Adapter

5.2 本シリーズの差別化ポイント

3パターン同時学習: 既存シリーズは単一または2パターンが中心
復習＋統合: 学習済みパターンの組み合わせに焦点
ASCIIアート: 既存シリーズにない題材
視覚的成果物: 目に見える出力でモチベーション維持

6. 内部リンク候補

6.1 前提シリーズ

6.2 関連シリーズ

テキストRPG戦闘エンジン（複数パターン）

作成日: 2026年1月30日 担当エージェント: copilot 参照元: 各パターンの調査ドキュメント、既存シリーズ構造案