Facade Pattern って何が美味しいの？

Facade Pattern って何が美味しいの？

Facade Pattern は、「一連の決まった処理」を取りまとめるためのクラス実装です。

「呼び出し側が制御を意識せず利用できる」「窓口(正面)を設けて外部と疎結合にする」といった話がされますが、
イマイチメリットがはっきりしません。

具体的な例をベースに Facade Pattern のメリットを考えてみましょう。

AuthFacade

アプリケーションで Facade がよく使われる場面の一つに、認証の例を上げることができます。

認証では、「ユーザ」や「認証セッション」などの要素を取り扱うケースが多く、
それぞれがクラスで構造定義されているでしょう。
Auth0 などの外部 IDaaS を利用する場合は、その Gateway なども存在しているかもしれません。

Auth Facade がない世界では、ユーザは 認証に関する手続きを、
どの構造から利用すべきかがはっきりしません。

で、この問題を、例えば「認証関連の手続きはユーザクラスから利用する」と定めたとしても、
今度は ユーザクラスが、セッションや Gateway に依存する事になり、ユーザクラスの実装が複雑になりがちです。

AuthFacade を利用することで、認証に関する手続きを AuthFacade 上にまとめることができます。

AuthFacade は認証に関連する各要素にすべて依存する形になりますが、
ユーザ、セッション、Gateway のそれぞれの構造は、それぞれに疎な状態を保つことができます。

CheckoutFacade

同様の例として 購入の Facade もよく見られる例です。

購入処理では、「ユーザ」「商品」「カート」など様々な要素が関連しており、
Facade なしで実装すると、お互いの構造が複雑な依存関係に陥りがちです。

CheckoutFacade を作成することで、これらの処理を CheckoutFacade に集中させることができます。

CheckoutFacade があるケースにおいて、実装側として意識するべきことは、
購入関連の処理を、CheckoutFacade からアクセスするべきという点に併せて、
「ユーザ」「商品」「カート」の各関係において、購入ロジックに起因するそれぞれの依存はすべて CheckoutFacade におく、ということも併せて注意しなければいけません。

Facade の利点

まとめると、 Facade の導入は以下のようなメリットをアプリケーション構造にもたらします。

1. 複数の構造を用いる手続きを一つのクラスにまとめることができる。
2. 呼び出し側の依存を、Facade クラスに集中させる事ができる。
3. 利用される構造同士の依存を解消する事ができる。

個人的には 3. のメリットが一番大きいかなと思っています。

構造同士が関連する処理で、どっちのクラスに書けばいいかなぁ…と悩むことが多いと思いますが、
そのようなケースでは、Facade を作成することで利用される側の構造の依存をよりシンプルに保つ事ができます。

Facade を作成する際には、クラス名で Facade を明記して、
コンストラクタ注入などを用いて、何と何の構造の Facade を作成しているのかを明記できるとより良いと思います。