BookmarkLINEBridgeパターン(ブリッジ・パターン)は、構造に関するデザインパターン手法の1つで、ブリッジ=橋、つまり「橋渡し」を行うクラスを挟む事で構造の効率化を図る事のできる処理モデルです。「橋」をイメージしてみます。A地点とB地点にかかる橋はもちろん横に伸びているはずです。縦に伸びているなんて、橋とは呼べません。(それってむしろ壁)Bridgeパターンはまさにこの「横につなぐこと」がイメージとしては最も大切な要素の1つです。このデザインパターン手法を紹介する時には良く「継承」が引き合いに出されます。ワインを扱うECサイトのアプリケーションのクラス群を考えてみます。継承を利用してこんな構成を考えました。ワインについて、赤と白を継承した国別のワインクラスがあります。赤と白それぞれに三ヵ国ずつぶら下がっていますが、もしここに「カルフォルニアワイン」を増やそうと思ったら、赤側と白側に合計2つのクラス追加が必要です。それだけで済めばよいですが、もし「ロゼワインも扱おう」となれば、赤と白と同じだけのクラスを「ロゼ用」として作成しなければなりません。追加が倍々になっていきます。コードの重複が発生します。やっていくうちに取り扱う国もクラスも増え続け、商売も上向きになってきた頃にオーナーがこう言いました。お客さんにわかりやすいように、「フランス」ではなく、「ボルドー(フランス)」「ブルゴーニュ(フランス)」のように、全ての国を産地で切っていこうよ。なるともうカオスです。継承が深くなると、こういう状況が生まれます。そこで満を持して登場するのがこの「Bridgeパターン」です。冒頭で述べた通り、Bridgeパターンは橋渡し、つまり「横」を繋ぐことによって構造を最適化できるデザインパターンです。先ほどのワインの構造をBridgeパターンで表現すると、以下のような関係になります。画で見ると結構イメージもわきやすいです。ワインの種類と産地で分類し、それらを橋渡しすることでワインのバリエーションを形成します。これなら産地にカルフォルニアを足そうが、種類にロゼを増やそうが変更は容易です。コードの重複も起こりません。Bridgeパターンとは、こういった構造を最適化できる、優れたデザインパターン手法になります。Bridgeパターンの基本的なクラス図は以下の通りです。今回はあるアプリケーションがデータを取得し表示する例で実装していきます。このアプリケーションでは、あるページで連続したデータを持つ配列を取得し表示していますが、表示箇所が不規則な為、一つずつ、任意の場所へ表示する必要がありました。この度、別の箇所で同じデータを用いてループで表示する処理が必要になりました。データを取り出すクラスから作成します。インターフェイスを定義します。今回はデモなのでデータベースからではなくjsonファイルをデータソースとし、データを取得します。getPointer();}それぞれ、ファイルを読み込む、表示する、データ個数、現在のポインタ位置を返却するメソッドを定義しています。このインターフェイスは、クラス図でいうところのImplementorに当たります。次に、このインターフェイスを実装し具象クラスを作成します。}}ここでの機能は最も基本的なものとなります。クラス図で言うところのConcreteImplementorです。ここまでで、データを取得する側、つまりはA地点の完成です。次は、データを表示する側、B地点を作成します。初期に実装していた、一つずつ、任意の場所へ表示するクラスです。}}ポイントはデータ周りを担当するクラスを継承ではなく委譲で受け取っている点です。ここがいわゆる「橋渡し」に部分になりますが、この例ではこうすることで、データの提供側と表示側が完全に分離しています。コストラクタで受け取ったオブジェクトを利用し、読み込みと表示メソッドをそのまま実行するように定義しています。次に、データの表示方法が増えた部分、ループでの表示処理が必要な場面が出てきた部分です。}}初代のクラスを継承した上で、今回必要な処理を定義しています。ここでも、データ取得係のクラスは委譲で受け取っています。最後に、これらを使って実際に表示を行います。'<h2>全て表示</h2>';$auto->autoDisplay();結果は以下のようになります。まとめ実装例は冒頭で紹介した例よりはかなり簡易的だったのでBridgeパターンによる恩恵はあまり大きくなかったですが、それでもここから規模を大きくしていくにつれてこのパターンで良かったと思えるでしょう。しておくことで、データの取得をjsonからデータベースに切り替える際も容易です。橋渡しのおかげで、役割間の依存が無いからです。このように、Bridgeパターンを用いると提供側と表示側それぞれで拡張を容易に行えるようになります。何かを追加や拡張する際にどこかにも余計にクラスを作成したりする必要がなくなるので、アプリケーションの規模が大きくなればなるほどその恩恵に肖る事が出来ます。コードの重複も防げます。いえ、Bridgeパターンというデザインパターンの1つはそれはそれとして、クラス設計時にはこうした構造に関してきちんと計画して実装したいものです。それを気づかせてくれるのも、デザインパターンならではです。パターンだけあって、JavaだろうがPHPだろうが、きちんとはまるあたりが先人の知恵とは素晴らしい。イベントレポート2019.12.8MySQL8.0.16で追加されたCHECK制約を試してみる。2019.12.2LaravelのContracts(契約)とは。SESを使ってAPIメール送信を行う(Mailableクラス&SimpleEmailService)2019.12.3MySQL8.0.16で追加されたCHECK制約を試してみる。RitoLaboこのサイトについて利用規約プライバシーポリシ。