Facadeパターン
そうか、普通に考えたらファサードなんて読めないか。
Facadeパターンでは、見逃しがちな点について補足しておいた。
まず、Facade役*1は一つのクラスでなければならないという誤解。
これはFacadeパターンの例としてよく見るから、ある程度は仕方ないのかな。
WikipediaのFacadeパターンの項目には、
関連するクラス群を使用するための手続きを、窓口となる一つのクラスに集約することにより、プログラムの冗長性を無くすことを目的とする。
Facade パターン
なんて書いてあるけど。
こういう風にFacadeパターンを理解していると、肥え太ったFacade役とか、凝集度の低いFacade役が出来てしまったりする。
ということで、Facade役が一つのクラスとなっているのは、あくまで実装の一つである、と考えた方がいい。
次に、Facadeパターンの使い道について。
本の中では、既存のサブシステムがあって、それをFacadeパターンにより隠蔽する例しか出ていなかったけど、もちろん既存のサブシステムだけに適用できるパターンではない。
設計段階で、低レベルなAPIと高レベルなAPIの両方を提供したい場合に、高レベルなAPIは低レベルなAPIを使用するような設計にした場合、それはFacadeパターンと呼べるだろう。
最後に、Facadeパターンで機能を追加すること*2の是非について。
これに関してはちょっと否定的で、出来るからと言ってそこに入れるのはちょっと安直過ぎじゃないかな？と思う。
なんというか、それはFacadeパターンそのものとは関係なくて、あくまで構成上たまたまそこに仕込める、みたいな。
