implementation-design-patterns

TypeScript デザインパターンのベストプラクティス（Refactoring Guru）

refactoring.guru をもとにまとめた、TypeScript における Gang of Four の 22 種類のデザインパターンの実装リファレンスです。3 つのカテゴリに分かれた 22 個のパターンファイルでは、それぞれの目的、課題、解決策、適用可能性、実行可能な TypeScript の例、実装手順、メリットとデメリット、および関連するパターンを取り上げています。

パターンは構造を決めるための語彙であり、処方箋ではありません。適用基準が目の前の課題に合う場合にのみパターンを取り入れてください。過剰な設計を防ぐため、すべてのパターンの項目に 使用すべきでない場合 のセクションがあります。

適用するタイミング

• 継承によって扱いにくくなったクラスをリファクタリングするとき。組み合わせの爆発、型に応じた条件分岐、複数の責務を持つ「神クラス」などが該当します
• 連携するオブジェクトがまだ定まっていない新しいモジュールを設計するとき。実装を変えられるようにしながら、インターフェースを安定させたい場合
• 互換性のないサードパーティの API、ライブラリ、レガシークラスを既存のコードに統合するとき
• リーフとブランチを同じように扱う必要がある、ツリー状のドメイン（ファイルシステム、組織図、式の AST、UI コンポーネントツリーなど）をモデル化するとき
• サブクラス化せずに、実行時に横断的な振る舞い（ロギング、キャッシュ、アクセス制御、デコレーションなど）を追加するとき
• 設定、ユーザー入力、環境条件に応じて、実行時にアルゴリズムや振る舞いのバリエーションを選択するとき
• 元に戻す／やり直し、履歴のスナップショット、トランザクションのロールバック、操作のスケジューリングやキューイングを実装するとき
• 多数のオブジェクト間の相互参照が複雑になった場合に、コミュニケーションを仲介するハブとして連携させるとき
• 何かが変化した際に、多数の購読者へ通知するとき。イベントシステムやリアクティブなデータフローなどが該当します
• パターンが暗黙的に使われているようなコード（kind による大規模な switch、並行するクラス階層、兄弟クラス間で共通するアルゴリズムの骨格など）をレビューするとき。パターンを明示しましょう

ルールのカテゴリ

#	カテゴリ	影響度	パターン	このグループを使う場面
1	生成	高	5	オブジェクトの構築が複雑、設定によって異なる、または具象クラスへの密結合のおそれがある場合
2	構造	高	7	各パーツの置き換え可能性を保ちながら、クラスやオブジェクトを組み合わせて大きな構造を作る場合
3	振る舞い	高	10	責務を分担し、実行時にオブジェクトがどのように連携するかを定める場合

使い方

1. 形を見極めます。 以下の クイックリファレンス を読み、どのパターンの目的が課題に合うかを特定します。パターンが当てはまる課題の多くは、一覧にあるフレーズのいずれかで表現できます。
2. パターンのリファレンスを読みます。 references/{category}-{pattern}.md を開きます。採用する前に、目的を確認し、適用可能性 と 使用すべきでない場合 を読んでください。
3. 例を調整します。 TypeScript の例では、説明用の名前（ConcreteStrategyA、Receiver）を使っています。マージする前に、ドメインに合った名前に変更してください。
4. 関連パターンを確認します。 各項目の末尾には 関連パターン が記載されています。同じ課題で検討する価値のあるパターンです。

クイックリファレンス

1. 生成パターン（オブジェクトのインスタンス化）

• creational-factory-method — サブクラスが、どの具体的な製品を作成するかを決定します。「生成側のコードに手を加えずに、新しい製品タイプを追加したいです。」 — HIGH
• creational-abstract-factory — 関連するオブジェクトのファミリーをまとめて生成します。「複数の対応するバリエーション（椅子＋ソファ＋テーブル）を扱うコードで、異なるファミリーを混在させたくありません。」 — MEDIUM-HIGH
• creational-builder — 複雑なオブジェクトを段階的に構築します。「コンストラクターのパラメーターが10個以上あるか、コンストラクターの引数が増え続けている兆候があります。」 — HIGH
• creational-prototype — オブジェクト自身の clone() メソッドで複製します。「具体的なクラスに依存せずにオブジェクトをコピーしたいです。」 — MEDIUM
• creational-singleton — グローバルなアクセスポイントを使って、共有インスタンスが1つだけであることを保証します。「このクラスのインスタンスをちょうど1つだけにしたいです。設定、レジストリ、プールなどです。」 — MEDIUM

2. 構造パターン（オブジェクトの構成）

• structural-adapter — あるインターフェースを別のインターフェースに変換します。「コードが期待するものとAPIが一致しないライブラリを使いたいです。」 — HIGH
• structural-bridge — 抽象化と実装を分離し、それぞれを独立して変更できるようにします。「直交する2つの要素があり、サブクラスの数が増え続けています。」 — MEDIUM
• structural-composite — 個々のオブジェクトとその集合を同じように扱います。「ツリー構造（フォルダー／ファイル、グループ／アイテム、コンポーネント／子要素）があり、葉と枝で同じインターフェースを使いたいです。」 — HIGH
• structural-decorator — サブクラス化せずに振る舞いを追加できるよう、オブジェクトをラップします。「同じインターフェースに対し、実行時に振る舞い（ロギング＋キャッシュ＋認証）を重ねたいです。」 — HIGH
• structural-facade — 複雑なサブシステムに対してシンプルなインターフェースを提供します。「クライアントコードが、サードパーティーライブラリの初期化や処理の調整に絡み合っています。」 — HIGH
• structural-flyweight — 多数のオブジェクト間で共通の状態を共有し、メモリを節約します。「似たようなオブジェクトを何百万個も生成していて、RAMが不足しています。」 — LOW-MEDIUM
• structural-proxy — 別のオブジェクトの代わりとなり、アクセスを制御します。「実際の対象に手を加えずに、遅延読み込み、アクセス制御、キャッシュ、またはロギングを実現したいです。」 — MEDIUM-HIGH

3. 振る舞いパターン（連携）

• behavioral-chain-of-responsibility — リクエストをハンドラーのチェーンに沿って渡します。 「検証／認証／解析のチェックを行うパイプラインがあり、チェックを動的に追加したり順序を変更したりしたいです。」 — MEDIUM-HIGH
• behavioral-command — リクエストを独立したオブジェクトに変換します。 「取り消し／やり直し、キューイング、スケジューリング、マクロの記録、または呼び出し側と受信側の分離が必要です。」 — HIGH
• behavioral-iterator — コレクションの内部表現を公開せずに走査します。 「構造がリスト、ツリー、グラフのどれなのかをクライアントが知らなくても、走査できるようにしたいです。」 — HIGH
• behavioral-mediator — 単一のハブでコンポーネント間の通信を一元管理します。 「フォームの各フィールドが互いを直接参照しており、結合が手に負えなくなっています。」 — MEDIUM
• behavioral-memento — カプセル化を損なわずにオブジェクトの状態を保存・復元します。 「取り消し／やり直しやトランザクションのロールバック用にスナップショットが必要です。」 — LOW-MEDIUM
• behavioral-observer — 状態が変化したとき、依存するオブジェクトに通知します。 「イベント、リアクティブ UI、pub/sub などで、あるオブジェクトが変化したときに多くのオブジェクトが反応する必要があります。」 — CRITICAL
• behavioral-state — 内部状態の変化に応じて振る舞いを切り替えます。 「status フィールドに基づく条件分岐が大量にあるステートマシンのクラスがあります。」 — MEDIUM-HIGH
• behavioral-strategy — アルゴリズムを実行時に切り替えられるようにします。 「複数のアルゴリズム（ソート、ルーティング、支払い、圧縮）があり、条件分岐を使わずに一つを選びたいです。」 — HIGH
• behavioral-template-method — 基底クラスでアルゴリズムの骨組みを定め、サブクラスで各ステップをオーバーライドします。 「複数のクラスでアルゴリズムの構造は共通ですが、ステップにわずかな違いがあります。」 — MEDIUM
• behavioral-visitor — クラスを変更せずにオブジェクト構造へ操作を追加します。 「AST のノードクラスには手を加えられませんが、5 つの無関係な操作を追加する必要があります。」 — LOW-MEDIUM

類似したパターンの選び方

いくつかのパターンは構造が似ていますが、異なる問題を解決します。各パターンの 関連パターン セクションを読んだうえで、次の違いを確認してください。

• Adapter と Facade と Proxy と Decorator — 4 つとも対象をラップします。Adapter はインターフェースを変更します。Facade はサブシステムを簡素化します。Proxy はインターフェースを維持し、アクセスやライフサイクルを制御します。Decorator はインターフェースを維持し、再帰的に振る舞いを追加します。
• Strategy と State — どちらも委譲先のオブジェクトを切り替えます。Strategy オブジェクトは互いに独立しており、クライアントが一つを選択します。State オブジェクトは互いを認識し、コンテキスト上で遷移を発生させます。
• Strategy と Template Method — どちらもアルゴリズムの一部を変化させます。Strategy はコンポジションを使います（実行時に切り替えます）。Template Method は継承を使います（コンパイル時に固定します）。
• Factory Method と Abstract Factory と Builder — Factory Method は単一のメソッドで一つの製品を返します。Abstract Factory は複数のメソッドで関連する製品群を返します。Builder は複雑な製品を段階的に組み立てます。
• Composite と Decorator — どちらも子を再帰的にラップします。Composite は子の結果を合計または集約します。Decorator は責務を追加し、処理を引き継ぎます。
• Chain of Responsibility と Command と Mediator と Observer — すべて送信側と受信側をつなぎます。CoR はリクエストをチェーンに沿って渡します。Command はリクエストを第一級のオブジェクトにします。Mediator は相互通信を一元管理します。Observer は 1 つの発行者から複数の購読者への通知を確立します。

関連スキル

• implementation-functional-patterns — このカタログがクラスを選ぶような問題に対する、TypeScript の関数型の解決策（HOF、ラムダ、パイプライン、ストリーム、合成）です。Strategy／Iterator／Command／Chain-of-Responsibility／Decorator／Template-Method の多くは、慣用的な TypeScript ではより軽量な関数型の形で実現できます。新しいクラス階層を導入する前に参照してください。

参考資料

1. Refactoring Guru — デザインパターンカタログ
2. Refactoring Guru — TypeScript の例
3. Refactoring Guru — 生成に関するパターン
4. Refactoring Guru — 構造に関するパターン
5. Refactoring Guru — 振る舞いに関するパターン