デザインパターン（2） Adaptor

まえおき

今日はAdaptorパターンについて。Wrapperパターンとも呼ばれるらしい。このパターンはごくごくあたり前のことを言っているだけのような気がするんだけど。保守のプログラミングをやる場合は無意識のうちに使っていることが多いと思う。

まとめ

• 既存機能と必要機能の「ずれ」を埋める。
• 実績のあるクラスを効率的に利用することでテスト工数を減らすことができる。

疑問点

• 継承を利用した方法と、移譲を利用した方法の使い分けがよく分からない。この本ではAdapteeが一つのクラスの場合しか説明されていないが、Adapteeが複数個あった場合は移譲を利用した方法しか使えない。Adapteeが一つのクラスなら継承、複数個のクラスなら移譲という使い分けでいいのだろうか？

その他

• 「無意識のうちに使っている」と冒頭で書いたけど、よく考えるとAdapteeをAdapterでラッピングしてClientが使うという実装しかしたことがない。これでもテスト工数を減らすという目的は果たせるけれど、設計上よろしくない。Clientが知るべきは使いたい機能だけなのでそれをTargetとして明示的に示してあげる必要がある。そうすることで開発者の意図が伝わりやすいソースコードができる。というか、ここまでやって初めてAdaptorパターンと呼べるのかな・・。

関連情報

• Adapterパターンを使い利用コンポーネントを切り替える　インターフェースの差異を吸収することで、ソースの改修を少なくすることができるということをうまく説明しています。また、クラスの生成をメソッド化するとさらに改修量が減るという説明もとても分かりやすいです。