概要
Bridge（ブリッジ）パターンは、
抽象（Abstraction）と実装（Implementation）を分離し、両者を独立に拡張可能にする設計パターンである。
機能の階層（例：図形やレポート）と、その実装手段（例：描画方式や出力形式）を分けることで、
組み合わせ爆発を防ぎ、構造を柔軟かつ明快に設計できる。
1. なぜBridgeが必要か？
❌ 機能と実装を階層的に継承すると、クラス数が爆発する
- Circle → SVGCircle / PNGCircle
- Square → SVGSquare / PNGSquare
→ 2 × 2 → 4クラス、3 × 3 → 9クラス… 組み合わせ地獄に突入
✅ 抽象と実装を別ツリーで設計し、コンポジションで柔軟に結合
circle = Circle(SVGRenderer())
circle.draw()
→ 実装を差し替えることで、機能はそのままに動作だけ変更できる
2. 基本構造
✅ Implementation（実装インターフェース）
class Renderer:
def render_circle(self, radius):
raise NotImplementedError
✅ ConcreteImplementations（具体的な実装）
class SVGRenderer(Renderer):
def render_circle(self, radius):
print(f"<circle r='{radius}' />")
class ASCIIArtRenderer(Renderer):
def render_circle(self, radius):
print(f"● 半径{radius}の円（ASCII表示）")
✅ Abstraction（抽象インターフェース）
class Shape:
def __init__(self, renderer: Renderer):
self.renderer = renderer
def draw(self):
raise NotImplementedError
✅ RefinedAbstraction（具体的な抽象）
class Circle(Shape):
def __init__(self, renderer: Renderer, radius: int):
super().__init__(renderer)
self.radius = radius
def draw(self):
self.renderer.render_circle(self.radius)
✅ 使用例
circle_svg = Circle(SVGRenderer(), 10)
circle_ascii = Circle(ASCIIArtRenderer(), 5)
circle_svg.draw() # <circle r='10' />
circle_ascii.draw() # ● 半径5の円（ASCII表示）
出力:
<circle r='10' />
● 半径5の円（ASCII表示）
3. Python的応用：関数を渡すことで動的Bridgeを構築
class Circle:
def __init__(self, draw_func, radius):
self.draw_func = draw_func
self.radius = radius
def draw(self):
self.draw_func(self.radius)
circle = Circle(lambda r: print(f"○ 半径{r} の円です"), 7)
circle.draw()
→ 関数やクラスを“ブリッジ”として渡すことで、動的な結合が可能
4. 実務ユースケース
✅ UIとテーマ（ライト/ダーク/高コントラスト）
→ UI構造とスタイルレンダリングを分離
✅ チャートと出力形式（HTML/PDF/PNG）
→ チャートの種類 × 出力方式を柔軟に拡張
✅ ロギングと出力先（コンソール/ファイル/リモート）
→ ロガー構造と転送手段を切り離す
✅ サービスと通信手段（REST/gRPC/WebSocket）
→ 同じAPI抽象に対して複数のプロトコルを実装
5. よくある誤用と対策
❌ 実装と抽象の分離が中途半端で、片方に依存が寄る
→ ✅ 「両者が独立に拡張できるか」を設計基準とする
❌ 実装の差し替えが前提でないのにBridgeを採用
→ ✅ 戦略的に差し替え・共通化が必要な場面に限定する
❌ Bridgeが巨大化し、責務が膨張する
→ ✅ Abstractionはロジックに徹し、Implementationは手段に徹する
結語
Bridgeパターンとは、“機能と手段を分けて考えることで、構造を自在に交差させる設計”である。
- 機能側（抽象）と実装側を独立に管理することで、柔軟で拡張性の高い構造が実現可能
- 組み合わせ爆発を抑えつつ、設計上の可読性・責務分離を強化
- Pythonではクラス・関数の双方を用いて、構造的な分離と合成を簡潔に実装可能
Pythonicとは、“足し算ではなく掛け算で構造を広げること”。
Bridgeパターンはその柔軟性の知性を、設計の交差点として昇華する技法である。