Bridgeパターン - 抽象と実装の分離
抽象と実装を分離するBridgeパターンをマスターしましょう。プラットフォーム非依存レンダリング、デバイスドライバー、APIレイヤーのTypeScript実装例。
詳細な説明
Bridgeパターン
Bridgeパターンは、抽象をその実装から分離し、両者が独立に変化できるようにします。2つの次元で機能を拡張する際のクラス階層の爆発的な増大の問題に対処します。
問題: クラスの爆発
Bridgeなしでは、形状（Circle、Square）とレンダラー（SVG、Canvas）を組み合わせるには4つのクラスが必要です。3つ目の形状を追加するとさらに2つ、3つ目のレンダラーを追加するとさらに3つ必要になります。これは乗法的に増大します。
Bridgeの解決策
合成で接続された2つの独立した階層に分割します。形状を追加するかレンダラーを追加するかがO(1)になります。
Bridge vs Adapter
Adapterは設計後に適用されることが多く、既存の互換性のないインターフェースを連携させます。Bridgeは設計の段階から計画され、抽象と実装を独立に変化させます。Adapterは修正、Bridgeはアーキテクチャです。
Bridge vs Strategy
どちらも合成を使用します。Bridgeはアーキテクチャレベルで抽象と実装を分離します（「ブリッジ」は恒久的）。Strategyは実行時にアルゴリズムを交換します。Bridgeは通常より広いインターフェースを含み、Strategyは通常単一のメソッドを含みます。
Bridgeが輝く場面
プラットフォーム（Web、モバイル、デスクトップ）をまたいで動作する必要があるクラス、抽象と実装の両方が拡張される可能性がある場合、またはクライアントから実装の詳細を完全に隠したい場合にBridgeを使用しましょう。
ユースケース
Bridgeは、クロスプラットフォームUIフレームワーク（抽象UIコンポーネントをプラットフォーム固有のレンダラーにブリッジ）、データベースドライバー（クエリビルダーをPostgreSQL/MySQL/SQLiteドライバーにブリッジ）、通知システム（メッセージタイプを配信チャネルにブリッジ）、リモートvsローカルリソースアクセスに最適です。