デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。 GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。
そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。
ついに、1/3を消化しました。 8回目は、機能の拡張と、実装の拡張を別々に管理するBridgeパターンのメモです。
Bridgeパターン
Bridgeパターンは、機能の拡張と実装の拡張を別々に管理するパターンです。
Bridgeパターンは、少し複雑な部類のパターンに入るかと思います。このパターンの意図は、機能のインターフェースと実装とを動的に切り替えたい場合や、拡張時のクラスの膨張を防ぎたいというものです。
例えば、OSに依存するシステムを作るとします。現在は、WindowsとMacのみに対応するシステムだとします。このシステムで提供する機能として、「プリント」機能と「インターネット」機能があるとします。
通常は、このようなクラス関係で作成すると思います。「オペレーティングシステム」インターフェースが、機能のインターフェースです。「Windowsクラス」「Macintoshクラス」が実装のクラスになります。
開放・閉鎖原則に則ってこのクラスに機能を付け加えるとすると、「Windowsクラス」に「Windowsクラス改」、「Macintoshクラス」に「Macintoshクラス改」をそれぞれ付け加えるというような変更になります。
ここでは、「テレビを見る」機能が追加されました。
このような変更を行っていくと、機能や実装が増えた場合に、クラスの数が膨大な数になってしまいます。
そこでこのBridgeパターンの出番というわけです。機能のクラスと実装のクラスをそれぞれ別々に管理して、クラスの増殖を防止します。
機能のクラスと実装のクラスとで用意する操作が変わったことに注目してください。
「テレビを見る」機能は「表示する」と「通信する」という実装でできると仮定しています。
開放・閉鎖原則を満たすためには、実装のクラスを変更するのは避けなければなりません。実装のクラスが増える分には問題ないのですが、既存の実装を変更するような機能拡張は、原則を破ることになります。
つまり、機能のクラスは、基本的に実装のクラスの操作の組み合わせでできる操作を拡張することになります。実装のクラスで提供できない機能を拡張する場合は、実装のクラスに手を入れることになります。この辺は、アプリケーションの要求や設計段階でクリアしておくべき問題となります。
パターンの適用タイミング
機能の拡張と実装の拡張を分けて考えるのがこのパターンでした。新しい機能を追加しようとした場合に、実装を意識せずに機能拡張ができます。
どの実装で機能を満たせるかは知っている必要があります。実装を意識しないのは、OSの例で言うと、どのOS実装が使われるかを意識しないということです。
Bridgeパターンの注意点としては、機能の拡張は、実装のクラスの組み合わせでできるパターンに限られるがあります。実装に手を加えなければ満たせない機能拡張は、Bridgeパターンの恩恵を受けるどころか、逆に修正の手間を必要としてしまう可能性があります。実装クラスで提供されるインターフェースは、アプリケーション要求・設計時に洗い出しておく必要があります。
機能拡張と実装拡張の組み合わせを動的に行いたい場合、サブクラスの作成を意図した組み合わせで管理したい(機能のクラスなのか実装のクラスなのか)これらの場合に、Bridgeパターンが使えると思います。
実装サンプルと参考文献
Bridgeパターンの実装方法をもっと詳しく知りたい場合は、下記のサイトにアクセスするのをお勧めします。もしくは、参考書籍を載せておきますので、そちらをお買い求めください。(^^;
日立ソフト(Bridgeパターン) 日立ソフト
Skeleton of GOF’s Design Pattern(JavaとC++のサンプルがあります) BRIDGEの骸骨
Mac Freaks(Bridgeパターン) Mac Freaks
デザインパターンのお勧め書籍
- 独習シリーズのデザインパターン編。デザインパターンを一人でも学べます。
- Sun Microsystemのお墨付き。GoF以外のパターンも学べます。
- UMLを使って、オブジェクト指向のいいとこ取りができます。
- デザインパターンだけではなく、ソフトウェア設計の原則やプラクティスまで学びたい人におすすめ