Facade パターンを例でわかりやすく解説

目的

サブシステムにある一連のインターフェイスに対して、統一されたインターフェイスを提供します。Facade パターンは、サブシステムを使いやすくする、より高レベルのインターフェイスを定義します。Gang of Four（GoF）の書籍にある7つの構造パターンの1つです。

解決する問題

オンラインショップを想像してください。注文するには複数のサービスが必要です。在庫の確認と確保、カードへの請求、決済が失敗した場合の在庫の解放、出荷の作成、確認メールの送信です。各サービスには独自のAPIと独自のルールがあります。

Webのチェックアウト、モバイルAPI、管理ツールなど、すべての呼び出し元がこれらの手順を自分で実行すると、同じ手順があちこちにコピーされます。コピーごとに順序を間違えたり、ロールバックを忘れたりするおそれがあり、すべての呼び出し元が5つのサービスに依存します。1つのサービスが変わると、すべての呼び出し元が変わらなければなりません。Facadeは手順を1か所にまとめ、呼び出し元に1つのメソッドを与えます。

構造と登場要素

TypeScriptでの実装

// Subsystem classes, each with its own API.
class Inventory {
  private stock = new Map([["book", 2]]);
  reserve(sku: string): boolean {
    const n = this.stock.get(sku) ?? 0;
    if (n === 0) return false;
    this.stock.set(sku, n - 1);
    return true;
  }
  release(sku: string): void { this.stock.set(sku, (this.stock.get(sku) ?? 0) + 1); }
}
class Payments {
  charge(card: string, cents: number): boolean { return card.startsWith("4") && cents > 0; }
}
class Shipping {
  createShipment(sku: string, address: string): string { return `SHIP-${sku}-${address.length}`; }
}
class Mailer {
  send(to: string, text: string): void { console.log(`mail to ${to}: ${text}`); }
}

Facadeは、1つのメソッドの背後で、ワークフロー全体を正しい順序で実行します。

// Facade: one method that runs the whole workflow in the right order.
class OrderFacade {
  constructor(private inventory = new Inventory(), private payments = new Payments(),
              private shipping = new Shipping(), private mailer = new Mailer()) {}

  placeOrder(sku: string, card: string, cents: number, email: string, address: string): string {
    if (!this.inventory.reserve(sku)) return "out of stock";
    if (!this.payments.charge(card, cents)) {
      this.inventory.release(sku); // roll back the reservation
      return "payment declined";
    }
    const shipmentId = this.shipping.createShipment(sku, address);
    this.mailer.send(email, `Order confirmed, shipment ${shipmentId}`);
    return "ok";
  }
}

const shop = new OrderFacade();
console.log(shop.placeOrder("book", "4111", 1999, "[email protected]", "1 Main St"));
// mail to [email protected]: Order confirmed, shipment SHIP-book-9
// ok
console.log(shop.placeOrder("book", "5500", 1999, "[email protected]", "2 Side St")); // payment declined

呼び出し元は、1つのメソッドを持つ1つのクラスに依存するだけになりました。ロールバックのルールはちょうど1か所にあります。サブシステムのクラスも引き続き利用でき、在庫を解放するだけでよい管理ツールは、Inventory を直接呼び出せます。

使うべきとき、使わないとき

次の場合はFacade パターンを使います。

• サブシステムが複雑で、ほとんどのクライアントが、その機能のうちの単純でよく使う一部だけを必要とする場合。
• クライアントコードと多くのサブシステムのクラスの間の依存関係の数を減らしたい場合。
• システムを層に整理し、各層への入口としてFacadeを置きたい場合。
• 大きなサードパーティのライブラリをラップし、コードの他の部分には必要な少数の操作だけを使わせたい場合。

次の場合は避けるか、使い方を限定します。

• サブシステムがすでに単純な場合。各呼び出しを1対1で転送するだけのFacadeは、何も隠さずに層を増やすだけです。
• Facadeが、システム中の無関係なメソッドやビジネスルールを集め始めた場合。これは「神オブジェクト」の問題で、1つのクラスが多くを知りすぎ、やりすぎています。焦点を絞った複数のFacadeに分割しましょう。

実際の利用例

• Node.js：fs.readFile() は、ファイルを開き、最後まで読み、閉じる処理を1回の呼び出しで行います。低レベルの fs.open()、fs.read()、fs.close() も引き続き利用できます。
• jQueryは、DOMや当時のブラウザー間の差異の前に、短く一貫した1つのAPIを置くことで、大きく普及しました。
• GoFの書籍の例はコンパイラです。1つの Compiler クラスが、スキャナー、パーサー、コードジェネレーターなどのサブシステムのクラスを、単にコードをコンパイルしたいプログラムから隠します。
• バックエンドアプリケーションのサービス層やAPIゲートウェイは、多くの内部サービスに対するFacadeとして機能します。

関連するパターン