概要
Bridge(ブリッジ)パターンは、
抽象(Abstraction)と実装(Implementation)を別々の階層に分けて独立に拡張可能にする設計パターンである。
継承に頼らず、"has-a" 関係をベースに拡張性と柔軟性を担保し、機能とプラットフォームの組み合わせ爆発を防ぐ。
1. なぜBridgeが必要か?
❌ 継承で機能・実装を両方組み合わせるとクラス数が爆発する
class WindowsButton: ...
class MacButton: ...
class WindowsCheckbox: ...
class MacCheckbox: ...
→ 新しいプラットフォームやUI要素を追加するたびにクラスが倍増
✅ 抽象と実装を分離し、それぞれを独立に拡張可能にする
ui = Button(WindowsRenderer())
ui.draw()
→ 「何をするか」と「どうやるか」を切り離し、柔軟に構成可能
2. 基本構造
✅ Implementation層(実装のインターフェース)
class Renderer:
def render_button(self, label):
raise NotImplementedError
✅ Concrete Implementations(具体的な描画方法)
class WindowsRenderer(Renderer):
def render_button(self, label):
print(f"[Windows] ボタン: {label}")
class MacRenderer(Renderer):
def render_button(self, label):
print(f"[Mac] ボタン: {label}")
✅ Abstraction層(抽象のインターフェース)
class UIElement:
def __init__(self, renderer: Renderer):
self.renderer = renderer
def draw(self):
raise NotImplementedError
✅ Refined Abstraction(具体的なUI)
class Button(UIElement):
def __init__(self, label, renderer):
super().__init__(renderer)
self.label = label
def draw(self):
self.renderer.render_button(self.label)
✅ 使用例
btn1 = Button("保存", WindowsRenderer())
btn2 = Button("保存", MacRenderer())
btn1.draw()
btn2.draw()
出力:
[Windows] ボタン: 保存
[Mac] ボタン: 保存
3. Python的応用:関数型Bridgeでさらにシンプルに
def render_button_windows(label):
print(f"(Win) {label} ボタン描画")
def render_button_mac(label):
print(f"(Mac) {label} ボタン描画")
class Button:
def __init__(self, label, render_func):
self.label = label
self.render = render_func
def draw(self):
self.render(self.label)
b = Button("送信", render_button_windows)
b.draw()
→ Pythonでは関数レベルでもBridge的構造を表現可能
4. 実務ユースケース
✅ UIツールキットにおけるクロスプラットフォーム描画
→ ボタン・入力欄などをOSごとに実装を切り替えて提供
✅ データの送信ロジックと転送プロトコルの分離(HTTP, WebSocket, gRPC)
→ 高レイヤーの抽象と低レイヤーの実装を疎結合で構成
✅ ログ出力とその媒体(コンソール、ファイル、リモート)
→ 同じ抽象操作を異なるバックエンドに橋渡し
✅ 支払い処理の戦略とプラットフォーム対応の分離
→ Payment(paypal)
, Payment(stripe)
のような動的切替が可能
5. よくある誤用と対策
❌ 実装と抽象が再び密結合になる
→ ✅ コンストラクタ注入を基本とし、実装の依存を明示的に外出し
❌ 継承の代替としての誤用(責務の分離がされていない)
→ ✅ 抽象=“意図”、実装=“手段” と明確に分離
❌ 抽象層が何を意味しているか不明確
→ ✅ ドメインモデルを先に設計し、何を分離すべきかを明示化する
結語
Bridgeパターンとは、“意図と手段の階層を分け、柔軟に結合し直す設計”である。
- 抽象と実装の独立を保つことで、機能の組み合わせ爆発を回避
- 継承よりも柔軟で、設計の方向性を自由に描き出せる
- Pythonではクラス・関数・依存注入によって、極めて簡潔かつ強力に表現できる
Pythonicとは、“機能と表現のレイヤーを分けて保ち、変化にしなやかに対応すること”。
Bridgeパターンはその分離と再構築の哲学を、設計の骨格に刻む技法である。