Wikipediaによれば、
"関連するクラス群を使用するための手続きを、窓口となる一つのクラスに集約することにより、プログラムの冗長性を無くすことを目的とする。"
http://ja.wikipedia.org/wiki/Facade_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
ってことらしいです。
"窓口となるクラス"とありますが、結局"ごちゃごちゃしたのを簡単に/シンプルに使えるようにする"ってのが大事だと思うので、窓口が単なるメソッドの場合とかでもあんまり気にする必要は無いと思います。
同様に、"関連するクラス群"ってのもごちゃごちゃしてればクラス群だろうがメソッド群だろうがあんまり気にする必要は無いと思います。
Facadeパターンはデザインパターンの中でももっとも自明なもののうちの一つというか、デザインパターンを学ばずともみんなやっていることだと思います。
お題
http://www.dofactory.com/Patterns/PatternFacade.aspx
上記サイトのサンプルをC++で書き直しました。
https://github.com/TakahashiShuuhei/DesignPatternPractice/blob/master/Facade.cpp
内容としては、Customerクラスのオブジェクトが住宅ローン(? mortgage)の適格者かどうかを確かめるために、本来はBankクラスやLoanクラスやCreditクラスを使う必要があるんだけどいちいちそれらをその都度呼び出すのは煩わしいからIsEligible()ってメソッドで一発で確かめられるようにしましょう、っていうことみたいです。
参考書でFacadeパターンを知ったとき、
「ん？ これって別にパターンとかじゃなくて当たり前のことじゃないの？」
と思いましたが、やっぱり当たり前のことみたいです。
毎回毎回 if(!bank_->HasSufficientSavings ... みたいな事を書くやつはやめちまえばいいと思います。
Facadeパターンを使うと、たとえば住宅ローンの適格者の判断基準が変わっても、変更するのはMortgageクラスのみでよいというメリットも見逃せませんね。
第1回ということで、まだまだどうなるか分かりませんができるだけ続けて行きたいと思います。
よろしくお願いします。
