design-patterns

デザインパターン

保守性、拡張性、テスト容易性に優れた TypeScript コードベースを構築するための、実証済みのアーキテクチャパターンです。Gang of Four の22パターンすべてを、実用的な実装とともに紹介します。

適用する場面

以下の場合に、これらのパターンを参考にしてください。

• 繰り返し発生するアーキテクチャ上の問題を解決する
• 密結合なコードをリファクタリングする
• プラグイン／拡張システムを構築する
• 依存性注入によってコードのテスト容易性を高める
• アーキテクチャ上の懸念がある PR をレビューする
• 継承とコンポジションのどちらを選ぶか検討する

パターンのカテゴリ

生成パターン

生成ロジックを利用側から隠し、柔軟にオブジェクトを作成します。

パターン	意図
Factory Method	オブジェクトの生成をサブクラスに委譲する
Abstract Factory	具体的な型に依存せず、関連オブジェクトのファミリーを作成する
Builder	複雑なオブジェクトを段階的に構築する
Prototype	一から構築する代わりに、既存のオブジェクトを複製する
Singleton	グローバルにアクセスできるインスタンスを厳密に1つにする

実装については references/CREATIONAL.md を参照してください。

構造パターン

クラスとオブジェクトを組み合わせて、より大きく柔軟な構造を形成します。

パターン	意図
Adapter	互換性のないインターフェースを連携させる
Bridge	抽象と実装を分離する
Composite	個々のオブジェクトとその合成物を統一的に扱う
Decorator	サブクラス化せずに、責務を動的に追加する
Facade	統一されたインターフェースで複雑なサブシステムを簡素化する
Flyweight	共通の状態を共有し、多数のオブジェクトにおけるメモリ使用量を削減する
Proxy	代替オブジェクトを介して、オブジェクトへのアクセスを制御する

実装については references/STRUCTURAL.md を参照してください。

振る舞いパターン

オブジェクト間のアルゴリズム、責務、通信を管理します。

パターン	意図
Chain of Responsibility	ハンドラーのチェーンに沿ってリクエストを渡す
Command	キューイング／取り消しのために、リクエストをオブジェクトとしてカプセル化する
Iterator	内部構造を公開せずにコレクションを走査する
Mediator	オブジェクト間の複雑な通信を一元化する
Memento	オブジェクトの状態を記録し、復元する
Observer	状態変更時に依存するオブジェクトへ自動的に通知する
State	内部状態の変化に応じて振る舞いを変える
Strategy	実行時にアルゴリズムを切り替える
Template Method	アルゴリズムの骨組みを定義し、手順の上書きをサブクラスに任せる
Visitor	オブジェクトを変更せずに操作を追加する

実装については references/BEHAVIORAL.md を参照してください。

パターン選択ガイド

問題	パターン
オブジェクト生成を分離したい	Factory Method, Abstract Factory
任意のフィールドが多い複雑なオブジェクト	Builder
オブジェクト生成にコストがかかり、コピーが必要	Prototype
グローバルに共有するリソース（設定、プール）	Singleton
互換性のないサードパーティ製インターフェース	Adapter
変化の軸が複数ある	Bridge
ツリー構造（ファイル、UI、組織図）	Composite
サブクラス化せずに機能を追加したい	Decorator
複雑な API を簡素化したい	Facade
類似オブジェクトが数千個あり、メモリを大量に消費する	Flyweight
遅延読み込み、アクセス制御、キャッシュ	Proxy
柔軟なリクエスト処理パイプライン	Chain of Responsibility
元に戻す／やり直し、タスクキュー、マクロ	Command
カスタムコレクションの走査	Iterator
多対多のオブジェクト間通信	Mediator
スナップショット、状態の保存／復元	Memento
イベントシステム、リアクティブな更新	Observer
オブジェクトの動作が状態に依存する	State
切り替え可能なアルゴリズム（ソート、圧縮など）	Strategy
固定された手順と可変部分を持つアルゴリズム	Template Method
異種オブジェクトに対する操作	Visitor

ベストプラクティス

実施すること

• 現在直面している実際の問題を解決するパターンを選びます
• 継承よりコンポジションを優先します
• 依存性注入を使ってコンポーネントを疎結合にします
• パターンの実装はシンプルに保ちます。過剰に作り込まないようにします
• パターンを選んだ理由を記録します（どのパターンかだけではありません）
• パターンを選ぶ際はテストのしやすさを考慮します
• 適切な場合はパターンを組み合わせます（例：Strategy + Factory）

実施しないこと

• 仮定上の将来のニーズに備えて、先回りしてパターンを適用しないでください
• 単純な関数やオブジェクトで十分な場合に、パターンを無理に適用しないでください
• 不要な抽象化レイヤーを作らないでください
• Singleton を隠れたグローバル変数として使わないでください
• コンポジションのほうが適している場合に、継承を選ばないでください
• チームの習熟度を無視しないでください。誰も理解できない「より優れた」パターンより、全員が知っているシンプルなパターンのほうが適しています

SOLID クイックリファレンス

原則	概要	関連するパターン
Single Responsibility	1 つのクラスに、変更する理由は 1 つ	Strategy, Command, Observer
Open/Closed	拡張に対して開き、変更に対して閉じる	Decorator, Strategy, Template Method
Liskov Substitution	サブタイプは基底型と置き換え可能でなければならない	Factory Method, Abstract Factory
Interface Segregation	小さく、目的を絞ったインターフェースを優先する	Adapter, Facade
Dependency Inversion	具象ではなく、抽象に依存する	インターフェース／抽象クラスを使うすべてのパターン