何かの処理を実装する場合、「何をするのか」は決まっていますが、「どうやって実現するのか」はいろいろ考えることができます。

例えば、データのソートです。「（何をするのか）ソートをする」は決まっていても、「どうやって実装するのか」には、バブルソートやクイックソート、マージソートなど様々な方法があります。

このような場合、それぞれの実装ごとにクラスを用意すれば、単純になりますが、クラスの数が膨大になってしまいます。また、機能を拡張しようとした場合、すべてのクラスを変更する必要がでてしまいます。クラスの数が多ければ多いほど、修正に要する作業が多くなります。

「何をするのか」と「どうやって実現するのか」を分けて考え、これらを結びつけるための橋を提供するパターンが、Bridgeパターンです。

Bridgeパターンの定義は、

　　抽出されたクラスと実装を分離して、それらを独立に変更できるようにする。

このパターンは、

• 「機能追加」（スーパークラスが持っていない機能をサブクラスで追加）を目的としたもの
• 「機能実装」（スーパークラスで定義したインターフェースをサブクラスで実装）を目的としたもの

この２つ（実装のクラス階層と機能のクラスの階層を分離し、以上を使って両者）の架け橋を提供するパータンです。このパターンは機能と実装がぐちゃぐちゃになってきたら使います。

このパターンを使用するメリットとしては、

• 実装クラスを追加するのが用意で、かつ見通しが良い
• 利用者側から実行時に動的に実装クラスを決めることができる

このBridgeパターンはAdapterパターンと似ていますが、Adapterパターンは既存クラスを利用して異なるインターフェースを持たせるためのもので、Bridgeパターンは実装と機能を明確に分離し、実装クラスと機能の橋渡しをするものです。

ということで、今日はBridgeパターンの紹介でした。