Facadeパターン

久々のデザパタですすみません(´・ω・`)

今日はFacadeパターンです。Facadeとは正面とか外見というフランス語？の言葉だそうです。デザインパターンの世界ではFacadeは「窓口」という意味で使ってます（正面とほぼ同じか・・・）

窓口ですので、「○○をお願いします。」と頼めば、その〇〇を関連項目も含めて全て処理してくれるということです。

Facadeクラスの例としては、以下のようにstaticメソッドを用意します。そのメソッド内では、必要な処理を実装します（あるいは、他クラスで実装されたメソッドを呼び出すなど）。

public class Facade {
    ・・・

    public static void doSample() {
        // 必要な処理を実装
    }
    ・・・
}

ユーザーは窓口に処理をお願いしましょう。

public class Main {
    public static void main(String[] args) {
        Facade.doSample();
    }
}

このパターンは、複雑な処理、例えばメソッドを適切な順番で過不足なく呼ぶ必要がある場合に威力を発揮します。それらの複雑なロジックを上記の例で言うdoSample()内でまとめ、中身を知らない人はただ単にdoSample()を呼べば済むということです。もちろん、doSample()を実装する人は仕様を詳しく知っている必要がありますが、開発メンバー全員がその仕様を知っている必要はないので、チームでコーディングする時には有効なパターンと言えます。

また、窓口を1つ用意して、利用者はそれを呼ぶだけでいいので、複数のメソッドを呼ぶケースと比べると、呼び出す側と呼び出される側の結合が緩いと言えます。結合が緩やかだと、部品として再利用しやすいです。

あとは、呼び出される側の「public メソッド」が少なくて済みます。これはカプセル化の話ですね。

ちなみに今回は窓口は1つしか例で示しませんでしたが、窓口が複数ある場合は当然考えられます。そして、窓口の窓口も大いにありえます。お願いごとは窓口に行けば十分ですからね。

関連パターン
「Abstract Factoryパターン」「部品を作って」とお願いすれば作ってくれるので、Facadeパターンと言えます。
「Singletonパターン」Facadeパターンは普通はSingletonです。インスタンス化して、複数の同じ窓口を作っても意味がありません。本には書かれていないですが、インスタンス化できないようにする（コンストラクタをprivateにする）としても良いと思います。
「Mediatorパターン」（勉強中）