implementation-design-patterns-python

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

**慣用的なモダン Python（3.10+）**での Gang of Four の22種類のデザインパターンの実装リファレンスです。refactoring.guru をもとにまとめています。3つのカテゴリにまたがる22個のパターンファイルには、それぞれ意図、問題、解決策、適用可能性（使う場合と使わない場合）、実行可能な Python の例と出力、実装手順、メリットとデメリット、関連する兄弟パターンが記載されています。

これは、TypeScript のデザインパターンスキルをPython らしさ優先で補完するものです。GoF パターンの多くは、Python では言語機能、つまり関数、ジェネレーター、データクラス、functools.singledispatch、match 文で表現できます。各項目では、まず慣用的な形式を紹介し、オブジェクトの同一性、保持する状態、実行時の登録、ポリモーフィックなディスパッチが本当に必要な場合に限り、GoF のクラスベースの構造を採用します。

パターンは構造を決めるための語彙であり、処方箋ではありません。適用基準に合う場合にのみ使ってください。Python では、このカタログを使う際によくある失敗は過剰設計なので、すべての項目にそれを防ぐための 使わない場合 セクションを設けています。

適用する場面

• コンストラクターのパラメーターが10個以上に増えている（テレスコーピングコンストラクターの兆候）、またはサブクラスがパラメーターの組み合わせを固定するためだけに存在している
• アルゴリズムや動作を選ぶため、メソッドが kind／type／mode／status に応じて分岐している — バリエーションが増えるたびに大きくなる match 文や if/elif の連鎖
• メソッド名がコードと一致しない、互換性のないサードパーティ API、ライブラリ、レガシークラスを統合している
• 葉と枝を同じように扱う必要がある、ツリー状のドメイン（ファイルシステム、AST、UI ツリー、組織図）をモデル化している
• サブクラス化せずに、ログ記録、キャッシュ、アクセス制御、圧縮などの横断的な動作を実行時に追加している
• 設定、ユーザー入力、環境に基づいて、実行時にアルゴリズムや動作のバリエーションを選択している
• 操作の取り消し／やり直し、履歴のスナップショット、トランザクションのロールバック、操作のキューイングやスケジューリングを実装している
• 多数のオブジェクト間で直接相互参照が複雑に絡み合っている — 通信を仲介するハブ
• 何かが変わったときに多くのサブスクライバーへ通知している — イベントシステム、リアクティブなデータフロー
• パターンが暗黙的になっているように見えるコードをレビューしている（巨大な if isinstance(...)、並行するクラス階層、コピー＆ペーストされたアルゴリズムの骨格） — 明示的にするか、Python らしい慣用表現に置き換える

ルールのカテゴリ

#	カテゴリ	影響度	パターン数	このグループを選ぶ場面
1	生成	高	5	オブジェクトの構築が複雑、設定によって異なる、または具象クラスへの密結合が懸念される
2	構造	高	7	部品を置き換え可能に保ちながら、クラス／オブジェクトをより大きな構造に組み合わせる
3	振る舞い	高	10	責任を分散し、実行時にオブジェクトがどのように連携するかを定義する

使い方

1. 形を見極めます。 以下のクイックリファレンスを読み、問題の意図に合うパターンを特定します。パターンに当てはまる問題の多くは、一覧にある表現のいずれかに似ています。
2. パターンのリファレンスを読みます。 references/{category}-{pattern}.md を開きます。意図を確認してから、採用する前に適用可能性と使わない場合を読みます。
3. 慣用表現から始めます。 各「正しい例」では、まず Python らしい形式を示しています。代替案のブロックにあるクラスベースの構造が必要でない限り、それを採用してください。
4. ドメインに合わせます。 例では、現実的で小規模なドメイン（交通手段、経路プランナー、ドキュメントツリー）を使用しています。マージする前に、用語を自分のドメインに合わせて変更してください。
5. 関連パターンを確認します。 各項目の最後には関連パターンがあり、同じ問題で検討する価値のある兄弟パターンを確認できます。

クイックリファレンス

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

• creational-factory-method — レジストリ／ディスパッチ用の辞書を通じて具体クラスを解決します。 「if/elif の分岐を並べずに、設定値や文字列キーでクラスを選びたいです。」 — HIGH
• creational-abstract-factory — 互いに対応する関連オブジェクトの一群を生成します。 「フラグを1つ切り替えると、連携する一式（ボタン＋チェックボックス）をまとめて切り替えたいです。」 — MEDIUM-HIGH
• creational-builder — 複雑なオブジェクトを段階的に構築します。Python では、まずキーワード専用の dataclass を検討します。 「コンストラクターの引数が10個以上ある、または段階的に組み立てる必要があります。」 — HIGH
• creational-prototype — copy.deepcopy／dataclasses.replace を使って複製します。 「これと同じものを、値を1つ変えてもう1つ作りたいです。」 — MEDIUM
• creational-singleton — モジュールのグローバル変数または functools.cache を使って、共有インスタンスを1つだけ用意します。 「テスト可能な状態を保ちつつ、設定／レジストリ／プールを1つだけ用意したいです。」 — MEDIUM

2. 構造パターン（合成）

• structural-adapter — クラスをラップして、呼び出し側が期待するインターフェースに合わせます。 「このライブラリのメソッド名が自分のものと一致せず、ライブラリを編集することもできません。」 — HIGH
• structural-bridge — 合成＋Protocol によって抽象と実装を分離します。 「直交する軸が2つあり、サブクラスの数が増え続けています。」 — MEDIUM
• structural-composite — 共通の Protocol と再帰を使い、葉とツリーを統一的に扱います。 「ツリーがあり、項目とグループに同じインターフェースを使いたいです。」 — HIGH
• structural-decorator — ラッパーを重ねる（または @decorator を使う）ことで、実行時に振る舞いを追加します。 「ログ記録＋キャッシュ＋圧縮を、任意の順序で重ねたいです。」 — HIGH
• structural-facade — 複雑なサブシステムに対して、単一の関数／モジュールを公開します。 「コーデックやビットレートの面倒な処理ではなく、convert(file, fmt) だけを使いたいです。」 — HIGH
• structural-flyweight — キャッシュ付きファクトリー＋__slots__ を使って、不変の状態を共有します。 「オブジェクトが数百万個あり、ペイロードの種類はごく少数しかないため、メモリが不足しています。」 — LOW-MEDIUM
• structural-proxy — __getattr__／cached_property を使って代理となり、アクセスを制御します。 「実際のオブジェクトに手を加えずに、遅延読み込み／認証／キャッシュを実現したいです。」 — MEDIUM-HIGH

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

• behavioral-chain-of-responsibility — リクエストを順序付けられたハンドラーのリストに渡して処理します。 「順序を入れ替えたい、認証／検証／認可チェックのパイプラインが必要です。」 — MEDIUM-HIGH
• behavioral-command — リクエストを、任意で取り消し可能な呼び出し可能オブジェクト／クロージャとして具体化します。 「取り消し／やり直し、キューイング、または複数の UI サーフェスで共有する単一のアクションが必要です。」 — HIGH
• behavioral-iterator — 内部を公開せず、__iter__／ジェネレーターを使って走査します。 「for x in my_structure をそのまま動作させたいです。」 — HIGH
• behavioral-mediator — 1 つのハブを通じてコンポーネント間のやり取りを仲介します。 「ウィジェット同士が互いを参照していて、再利用できません。」 — MEDIUM
• behavioral-memento — 凍結データクラスを使って状態をスナップショット／復元します。 「プライベートフィールドを公開せずに、取り消し／ロールバックしたいです。」 — LOW-MEDIUM
• behavioral-observer — 変更時にサブスクライバーのコールバックへ通知します（多くの場合、property セッターを使用します）。 「1 つの値が変わったときに、多数のオブジェクトが反応する必要があります。イベントやリアクティブ UI などです。」 — CRITICAL
• behavioral-state — ポリモーフィックな状態オブジェクト（または enum とディスパッチ）に処理を委譲します。 「クラスがステートマシンになっていて、すべてのメソッドに if status == があります。」 — MEDIUM-HIGH
• behavioral-strategy — アルゴリズムを Callable として渡し、実行時に切り替えます。 「複数のアルゴリズム（ソート／ルーティング／支払い）を条件分岐なしで選びたいです。」 — HIGH
• behavioral-template-method — ABC で処理の骨格を定め、サブクラスで各ステップをオーバーライドします。 「複数のクラスでアルゴリズムを共有しつつ、一部のステップだけを変えたいです。」 — MEDIUM
• behavioral-visitor — functools.singledispatch／match を使って操作を追加します。 「ノードクラスを編集せずに、AST 全体で 5 つの操作を実装したいです。」 — LOW-MEDIUM

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

形が似ていても、異なる問題を解決するパターンがいくつかあります。各パターンの関連パターンのセクションを読み、次の違いを踏まえて選んでください。

• Adapter、Facade、Proxy、Decorator の違い — 4つとも対象をラップします。Adapter はインターフェースを変更します。Facade はサブシステムを簡素化します。Proxy はインターフェースを維持し、アクセスやライフサイクルを制御します。Decorator はインターフェースを維持し、再帰的に振る舞いを追加します。
• Strategy と State の違い — どちらも差し替え可能なオブジェクトに処理を委譲します。Strategy の各バリアントは独立した関数で、呼び出し側が選択します。State オブジェクトは互いを認識し、コンテキストの状態遷移を引き起こします。
• Strategy と Template Method の違い — どちらもアルゴリズムの一部を変化させます。Strategy はコンポジションを使います。実行時に差し替える Callable です。Template Method は継承を使います。定義時に固定される ABC の骨格です。
• Factory Method、Abstract Factory、Builder の違い — Factory Method は1つのプロダクトを選び出します（レジストリ／@classmethod）。Abstract Factory は互いに対応するプロダクトのファミリーを返します。Builder は1つの複雑なプロダクトを組み立てます（キーワード専用のデータクラス、または段階的な構築に使う流れるようなインターフェースのビルダー）。
• Composite と Decorator の違い — どちらも子要素を再帰的にラップします。Composite は子要素の結果を集約します。Decorator は1つの責務を追加し、処理をそのまま引き継ぎます。
• Chain of Responsibility、Command、Mediator、Observer の違い — いずれも送信側と受信側をつなぎます。CoR はハンドラーのリストに沿ってリクエストを渡します（途中で止めることもできます）。Command はリクエストを第一級の呼び出し可能オブジェクトにします。Mediator は多対多の通信を一元管理します。Observer は1つのパブリッシャーから複数のサブスクライバーへの通知を確立します。
• Visitor：singledispatch、match、メソッドの使い分け — クラスを編集せずに、閉じた型集合に対する操作を追加するには functools.singledispatch を使います。すべてのケースを1つの網羅的な関数にまとめたい場合は match を使います。操作が1つだけで型の種類が少ない場合は、通常のメソッドを使います。

参考資料

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