世の中には個人的にしか利用しない簡単なシステムから世界規模で大々的に利用されるシステムまで、大小さまざまなシステムがあります。

最初はごく簡単な機能だけしかなかった小さなシステムも、度重なる機能拡張や修正で徐々にそのシステムは大きくなっていきます。システムの規模が大きくなればなるほどクラスの数は増えていき、それに従ってクラスどうしの関係も複雑になっていきます。クラスどうしの関係が複雑になってくると、それを利用する側に急激な負担が発生します。

ありがちな話として、「このクラスはあのクラスと一緒に使う必要がある」とか「このクラスを使う場合は、前もってこちらのクラスのメソッドを呼び出し、あらかじめ処理をしておかなければいけない」といったものです。つまり、あるクラスを利用するために複数の他のクラスを知っている必要がある。ということです。

こういった状況では、利用する側にミスが発生しやすくなり、思わぬ不具合やシステム障害の原因になってしまいます。また、システムのセキュリティ面では、使い方が複雑になればなるほどセキュリティの確実な確保がしにくい状況になります。

もし、クラスどうしの複雑な関係を意識しなくても利用できるシンプルな「窓口」があればどうでしょうか？利用する側は非常に便利になり、ミスが少なくなりそうですね。またセキュリティの確保も、バラバラなクラスどうしのままよりは格段に改善されそうです。
このような場面でFacadeパターンが活躍します。

Facadeパターンの目的は、GoF本では次のように定義されています。
サブシステム内に存在する複数のインターフェースに1つの統一インターフェースを与える。
Facadeパターンはサブシステムの利用を容易にするための高レベルインターフェースを定義する。 

Facadeは「（建物の）正面、窓口」という意味です。
Facadeパターンは、複雑な内部処理(データベース処理・業務処理など)を隠蔽し、利用者にシンプルなインタフェースを提供するパターンです。また、複雑なAPI呼出しの適切な実行順を利用者に意識させないという目的もあります。
Facadeパターンは、複雑に関連しあうクラス群を隠蔽するようなクラスを用意し、そのクラスに統一されたAPIを実装します。利用側はそのAPIを通じてクラス群を利用します。
一般的に、システムがある規模より大きくなると、より小さなサブシステム単位に分割されます。このサブシステムをシンプルに利用できるようにするためにFacadeパターンが利用されます。Facadeパターンを適用すると、あるAPIだけを呼び出すだけでサブシステムを利用できるようになります。 また、サブシステムどうしの依存関係もシンプルになります。

最後に、Facadeパターンのメリットについてですが、

• サブシステムの構成要素を隠蔽する
• サブシステムとクライアントの結びつきを緩くする

などが挙げられます。

ということで、複雑なクラス関係をシンプルにするための統一インターフェースを提供するFacadeパターンについてでした。