デザインパターン第２回「Facadeパターン」

複数人の開発者で、オブジェクト指向言語を用いて１つのシステム開発を行う場合、
開発者は「クラスを作る人」と「クラスを使う人」という２つの立場を使い分けることになります。

開発者が「クラスを作る人」の立場に立ったときは、
クラスを使う人に楽をさせるための“工夫を惜しまない”ようにするとよいだろう。
常に、自分が「クラスを使う人」の立場になって、よく吟味してクラスを作るとよい。
それが、オブジェクト指向プログラミングを効果的に実践するための秘訣である。
作る人は、使う人の立場に立って考えて作る「思いやり」の精神が必要。
これは他の物作りの仕事と同じように、プログラミングの世界においても大切なことである。

また、クラスを使う人が「このクラス、ちょっと使いづれえな。」と思ったら、
クラスを作った人(設計をした人）に、そのクラスがどのように使いづらいのか、
どのようにすると使いやすくなるのかを具体例を述べて、提案あるいは相談をし、
その結果、機能追加やリファクタリングが可能であれば、積極的に行うとよいだろう。
なぜなら、その繰り返しによって、クラスの価値が高まることとなるからだ。
ひとりの開発者(設計者)によるアイディアや想定には限界があるため、*1
開発者同士のコミュニケーションを密にすることによってそれを補い、クラスの価値を高めるとよい。

では、前置きの小話はその辺にして・・・、
今回はGoF デザインパターンの中から「Facadeパターン」をぬるーく解説します。

■Facadeパターンの概要■
このパターンは複数のクラスを束ね、統一したインターフェイスを提供するためのパターンです。
Facadeを構成するクラス群は、 Facadeとの直接的な双方向の関連はもちません。
Facadeは、あくまでクラス群を利用するだけの立場に留まります。
よって、 Facade を適用したり変更することによって、各クラスには影響を与えないことが原則です。
複雑になったクラス同士の依存関係を整理し、実行順序を整え、
機能を利用しやすい形にするのが Facadeの役割となります。
複雑なモノは、簡単に利用できるようにしておきましょうという考え方。

開発を進めていくと、はじめは小さなものでも、だんだんと規模が大きくなる。
規模が大きくなればなるほど、多くのクラスが出来て、相互関係が複雑になってくる。
複数のクラスを利用する場合、それらの関係を理解して正しい順番にメソッドを呼び出す必要がでてきます。
そんなとき、その処理を行うための「窓口」を用意しておくことで、個別にたくさんのクラスを制御しなくても、
「窓口」に対して要求をするだけで、目的の処理を行えるようになる。これをFacadeパターンと呼びます。

例えば、３つのクラスが持つおのおののメソッドを呼び出すことで、ある目的が達成されるとします。
クラスを使う開発者は、「いちいち３つもクラスを使うなんて、面倒くせえなあ」と愚痴を漏らします。
それなら、３つのクラスを使う処理を請け負ってくれる、窓口となるクラスＤを作るとどうだろう。
クラスを使う人は、クラスＤだけを使えば目的を達成することができるようになります。
これは、ただ単に開発者が楽になるというだけでなく、
窓口となるクラスＤが、正しい順番で確実にクラスを扱ってくれるので、
開発者によるケアレスなバグを未然に防いでくれることにもつながります。

Facadeパターンのまとめ

Facadeパターンは、既存のクラスを複数組み合わせて使う手順を、
「窓口」となるクラスを作ってシンプルに利用できるようにするパターンです。
これは、実に単純明快なアイディアであるため、Facadeパターンの存在を知らなくとも、
OOPを実践しているプログラマであれば、このパターンを無意識的に利用している人も多いだろう。
まあ、知らなかった人は今後ご利用くださいませってことで・・・どんまい。^^;

ちなみに、Facade（ファサード）とはフランス語を語源とする単語で「見かけ」という意味です。
内部で複数のクラスを使っているが、それを使う側にはそれを意識させず、
「あたかも１つのクラスに見せかけている」ってことですな。

とても簡単なパターンなので、今回はサンプルコードは用意しません(´・ω・｀)

*1:利用者(開発者)が用意してほしいプロパティやメソッドを全て事前に洗い出し、全て網羅することは、なかなか難しいものです。人間ですもの、見落としはあります^^;