【オブジェクト指向のこころ】10章 Bridgeパターン

「デザインパターンとともに学ぶオブジェクト指向のこころ」の学習記録。
「第10章 Bridgeパターン」のまとめ。

Bridgeパターンの目的
適用例
まとめ

Bridgeパターンの目的

GoFによるとBridgeパターンの目的は以下の通り。

実装から抽象的側面を切り出して、それらを独立して変更できるようにする。

ここでの実装とは、抽象クラスとその派生物が自らを実装するために必要とするものを意味する。
抽象クラスの派生物、つまり具象クラスを実装と呼ぶ場合もあるが、ここでの意味とは別ものである。

適用例

2つの描画プログラムDP1とDP2を用いて四角形を描画するプログラムの開発例。

DP1とDP2のどちらを使うかは、四角形を表すクラスを実体化した時点で決定できる。
そこで次のような設計をおこなった。

その後、四角形だけでなく円もサポートするよう要求された。
ClientとしてはRectangleとCircleを区別なく扱いたい。

この場合は同じアプローチで、Shape（形状）という階層を1つ追加するだけで対応できる。

このアプローチの問題点1

もう一つ描画プログラム（DP3）が追加された場合、2種類の形状×3種類の描画プログラムとなり6種類のShape型を作成することになる。

このアプローチの問題点2

さらに新たな形状（三角形）が追加された場合、3種類の形状×3種類の描画プログラムとなり9種類のShape型を作成することになる。

この状態はクラス爆発と呼ばれる。
この問題は、抽象的側面（Shapeの種類）と実装（描画プログラム）が緊密に結合しているため発生する。

この問題を解決するには、実装における流動的要素から抽象的側面における流動的要素を切り出す必要がある。
これにより、要求の増加とクラス数の増加を線形の関係にする。
つまり1つの要求に対しクラスの増加は1つにしたい。

代替案

継承階層を変更してみる。
これでも形状3×描画プログラムのバージョン3=9クラス発生し、同様にクラス爆発が発生する。

Bridgeパターンの適用

Bridgeパターンは、ある抽象的側面と様々な実装が共存している場合に利用することができる。
このパターンにより、実装と抽象的側面を、お互いの存在を気にかけることなく別々に変更できるようになる。
お互いの存在を気にかけることなくとは、実装を変更することなく新たな抽象的側面を追加できるようになり、逆に、抽象的側面を変更することなく新たな実装が追加できるようになるということを意味している。

流動的要素を確認すると、様々な形状と、様々な描画プログラムがある。
つまり共通する概念は形状と描画プログラムということである。

Shape: 自らの描画方法を知っておくという責務がある
Drawing: 直線や円を描画するという責務がある

このような責務をクラス内にメソッドで表現する。

この2つのクラスの関係性を考える。
一方のクラスがもう一方を使用することを考えると2つのパターンがある。

DrawingがShapeを使用する
ShapeがDrawingを使用する

前者の場合、Drawingが描画するときにShapeの形状が具体的には何なのか（RectangleかCircleかTriangle）を知る必要が出てくる。
これでは具体的な形状がShapeにカプセル化されている意味がなくなる。

後者の場合、ShapeにDrawingオブジェクトの参照を保持しておけば、ShapeはDrawingの型の詳細（V1DrawingかV2DrawingかV3Drawingか）を知る必要がない。
描画方法（Drawingのメソッド）は形状の詳細が知っていれば良い。
例えばRectangleとTriangleはDrawing#drawLine()を使うことを知っている。
CircleはDrawing#drawCircle()を使うことを知っている。
これは本書p.163のコード例を見ると詳細がよく分かる。
また描画を制御するというDrawingの責務も守られている。

DrawingのdrawLineメソッドは、Rectangleのdrawメソッドから直接呼び出せる。
しかしShape内のdrawLineメソッドから呼び出すようにしている。
これによりRectangle以外の、drawLineを呼び出したい別の形状（Triangle）からもこのメソッドを呼び出せるようにしている。