AdapterパターンとBridgeパターン

Bridgeパターン　＜機能と実装は分ける＞

階層クラスの問題点を考えてみましょう。クリーナー（掃除機）を例にクラスの説明をします。UML図（図3-1）をご覧ください。

家庭で使用するクリーナー（掃除機）をモデルとした階層図です。掃除機にはコンセント式とコードレス式（充電方式など）があり、それぞれゴミの吸引方式にサイクロン式とフィルタ式（紙フィルタを使用するもの）が存在しています。

このクラス図では階層式になっており、すっきりしたモデルになっています。

機能として、コンセント式とコードレス式、実装としてサイクロン式とフィルタ式があるとも読み取れます。ここで言う「機能」とは予定されているものを意味し、「実装」とは実現する手段のようなものと考えていただければよいかと思います。

しかしこの構造には大きな問題があります。

・機能拡張があった場合、（200Vコンセント式を追加するなど）全種類にサイクロン式とフィルタ式を追加しなければならない。クラス追加が困難である。

・実装に使われるコードに複製が生じる可能性がある。たとえば、AC100V式のサイクロン式と、コードレス式のサイクロン式では、同じようなコードが存在する可能性が高い。

これを解決するためにはどうしたらよいでしょうか？

Bridgeパターンによる解決方法

上記のクリーナークラスの階層図の構成を、下記のとおりに変更してみます。UML図で確認してみましょう（図3-2）。機能と実装を分離してそれぞれ独立に拡張できるようにします。

実装にパワーブラシ付きが追加になっています。前の階層型構造では、同じことを行うには、すべての機能に追加しなければなりませんでした。

これは、機能と実装を分離することで、それぞれの拡張を独立して行えるようになったことを表します。機能のクラスと実装のクラスを橋渡しすることで、実装部分は隠されます。Bridge（ブリッジ）パターンの名前は、この橋渡しの構造を意味します。また、実装部分が隠されることで、利用者にも不要な部分を見せないといったメリットも出てきます。

このように、Adapterパターン、Bridgeパターンともクラス構造とクラスの関連に工夫を持たせることで、プログラミングを楽にするメリットが見えてきたと思います。サンプルコードも参考にしてください。

最終回となる次回は、Chain of Responsibilityパターンの紹介を行い、オブジェクトの振る舞いについて紹介をさせていただく予定です。