python-design-patterns

Python のデザインパターン

想像上の将来的な柔軟性ではなく、次に実際に行う変更に備えて設計しましょう。複雑さに見合う価値が生まれるまでは、シンプルなコードが最善です。

具体的な変更前／変更後の例については、references/pattern-catalog.md をお読みください。

判断の原則

• KISS： 現在の要件を満たす、最もシンプルな設計を選びます。
• 単一責任： 関数／クラス／モジュールごとに、変更する理由を一つにします。
• 継承よりコンポジション： 脆弱な階層構造を作る前に、振る舞いを明示的に組み合わせます。
• 三度目の正直： 三つ目の例によってパターンが実在すると確認できるまでは、似た二つのケースを抽象化しません。
• 依存関係の方向： ビジネスロジックは、フレームワークの連携コードに依存させません。

リファクタリングのワークフロー

1. 問題点を特定します。重複、結合度の高さ、長い関数、責任の所在の不明確さ、テストの難しさ、または繰り返し発生するバグのパターンなどです。
2. 設計で対応すべき変更を明確にします。
3. 問題を軽減できる最小の境界を見つけます。
4. クラスより先に、純粋関数の抽出を優先します。
5. 実際の重複を解消するか、変動する部分を切り離せる場合にのみ、抽象化を追加します。
6. コードを移動する前に、振る舞いを確認するテストを用意します。

よくある手法

• 一貫した変換処理を関数として抽出します。
• 関連する関数がまとめて変更される場合は、モジュールとして抽出します。
• 複数の実装がすでに存在する場合は、プロトコル／インターフェースを導入します。
• テストしやすくするため、依存関係をパラメーターとして渡します。
• 永続化処理やビジネスロジックが実際に絡み合っている場合にのみ、リポジトリ／サービスの境界を設けます。

避けるべきこと

• 実際に複数のバリエーションが存在する前に、ファクトリー、レジストリ、プラグインを導入すること。
• サブクラスが一つしかない基底クラス。
• グローバルな可変状態。
• 公開 API スキーマに漏れ出すフレームワークモデル。
• 呼び出しを転送するだけの「クリーンアーキテクチャ」レイヤー。

出力

次の内容を返します。

• 現在の設計上の問題点；
• 問題を引き起こしている具体的な要因；
• 最小限のリファクタリング；
• 現時点で避けるべき抽象化；
• テストへの影響；
• 変更前／変更後の責任境界。