AdapterパターンとBridgeパターン
デザインパターンは、先人たちの知恵のエッセンス
前回のデザインパターンでは、生成に関するパターンとしてFactoryMethodパターンを取り上げました。
第2回に取り上げるのは、構造に関するパターンのうちの2つ、AdapterパターンとBridgeパターンです。前回と同じようにUMLとサンプルコードを元に解説していきたいと思います。
ここで、AdapterパターンとBridgeパターンの説明に入る前に、もう一度デザインパターンを学習する意味を考えてみたいと思います。
デザインパターンを知らなくともプログラムは書けます。では、なぜデザインパターンを学習するのでしょうか？デザインパターンを知ることによるメリットは何でしょうか？
それは「生産性」と「メンテナンス性」と説明しました。
オブジェクト指向を使用するプログラムは、初心者と達人とで大きく異なってきます。初心者から見ると達人のプログラムは難しくて理解に苦しみ、達人にとっては初心者のプログラムは修正しにくいものです。プログラミングされたものが工業製品である以上、品質に差が出るのはマイナス要素です。この差をできるだけ少なくするためにも、最初に先人たちの知恵のエッセンスであるデザインパターンを学び、オブジェクト指向の本来の意味を理解しておきましょう。
本記事中にあるサンプルコードを実際に入力・実行し、そのふるまいを確かめてください。そして、UMLでその構造とふるまいをイメージできるようになりましょう。
Adapterパターン ＜間にはさんでかみ合わせ＞
異なるインターフェースを持つクラスの間にはさむことによってクラス間をつなげる役目をするのが、Adapterパターンです（図1）。どのようなふるまいをするのか、サンプルコードを見てみましょう。
この例では、2つのクラス（InLiveとAdaptee_TV）があります。どちらもプログラム上修正・変更できないクラスであると仮定しましょう。メソッドの内容は音楽を鑑賞するというものですが、InLiveクラスはRequest()、Adaptee_TVはspecific_Request()とメソッドの名称が異なっています。
Adapterクラスはこの2つのクラスの間に入り、Request()メソッドでspecific_Request()を実行させようとします。
実際にAdapterクラスの内部にAdaptee_TVクラスを包含します。InLiveクラスとインターフェース（ITarget）をあわせることで、Adaptee_TVクラスはRequest()メソッドを実装しなければならなくなります。
Request()メソッドの中で包含したAdaptee_TVクラスのインスタンスメソッドspscific_Request()を委譲します。こうすることで、2つのクラスをつなぐことができます。
