Java デザイン パターン - 外観パターン

概要

今日説明する外観パターンは、比較的単純なデザインパターンであり、日常の開発で時々使用するかもしれませんが、それがデザインパターンであるとは思ったこともないかもしれません。この記事で説明する外観モードをできるだけ網羅的に説明するために、いくつかの例から始めます。それがあなたにとって有益であることを願っています。

引用

ここに引用を挿入する目的は、日常の開発で出現パターンを使用するときに思い出してもらうことです。

もしかしたら、あなたの上司があなたのためにこのような仕事を手配してくれるかもしれません。これはコア モジュールである可能性があり、モジュールにはその機能の 1 つが含まれますが、上司は呼び出し用のインターフェイスを提供することだけを望んでいるかもしれません。彼はこう言います: こんにちは、Xiao Ming。現在のシステムにはコア機能 P0 が必要です。それを実装してください。コードの内部ロジックを知る必要はありません。どうぞ。

そのようなタスクを頻繁に割り当てられる場合は、外観モードをマスターしている必要があると思います。

定義

外観パターンは、サブシステム内のインターフェイスのグループにアクセスするための統一インターフェイスを提供します。ファサード パターンは、サブシステムを使いやすくする高レベルのインターフェイスを定義します。

非出現モード

ここでは、「Dahua Design Patterns」という本の例を使用しています。この例は非常に鮮やかだと思います。ここで、あなたが株式投資家であると想像してください (ブロガーが株式取引をしていないだけで、ここに何か問題があるかどうかはわかりません。もしそうであれば、見なかったことにしてください。^_^) 、財務管理活動を行いたいと考えています。あなたは 2 つの株、1 つの国債、1 つの不動産に興味を持っています。

今このコードを書くように頼まれた場合、コード フレームワークは次のクラス図のように見えるかもしれません:

他の財務管理活動のロジックは株式のロジックとは異なるため、ここには株式コードのみがリストされています。 . は一貫しています。冗長コードにはスペースを占有する以上の利点はありません。

StockA.java

public class StockA {
    private int stockCount = 0;
    public void sell(int count){
        stockCount -= count;
        System.out.println("卖了" + count + "支 A 股票");
    }

    public void buy(int count){
        stockCount += count;
        System.out.println("买了" + count + "支 A 股票");
    }
    public int getStockCount() {
        return stockCount;
    }
}

次のコードは財務管理者向けであり、単純な売買ロジックの場合、財務管理者は非常に多くのコード処理を費やす必要があり、これは本当に苦痛です。

Investors.java

public class Investors {

    public static void main(String[] args) {
        StockA stockA = new StockA();
        StockB stockB = new StockB();
        NationalDebt debt = new NationalDebt();
        RealEstate estate = new RealEstate();

        stockA.buy(100);
        stockB.buy(200);
        debt.buy(150);
        estate.buy(120);

        stockA.sell(100);
        stockB.sell(200);
        debt.sell(150);
        estate.sell(120);
    }
}

上記はアピアランスモードを使用せずに書かれたコードです。つまり、以下で説明する外観モードを使用すると、コードをより単純かつ明確にすることができます。

外観モード

上記の非外観モードでは、あまりフレンドリーではないコードロジックがいくつか見られます。アピアランス モードは、呼び出し元にとってより透過的なように、より高いレベルのカプセル化に基づくことができます。以下は、変更された外観モードのクラス図です。

FundFacade.java

public class FundFacade {

    private StockA stockA = null;
    private StockB stockB = null;
    private NationalDebt debt = null;
    private RealEstate estate = null;

    public FundFacade() {
        stockA = new StockA();
        stockB = new StockB();
        debt = new NationalDebt();
        estate = new RealEstate();
    }

    public void buyAll(int count) {
        stockA.buy(count);
        stockB.buy(count);
        debt.buy(count);
        estate.buy(count);
    }

    public void sellAll(int count) {
        stockA.sell(count);
        stockB.sell(count);
        debt.sell(count);
        estate.sell(count);
    }

    public void buyStockA(int count) {
        stockA.buy(count);
    }

    public void sellNationalDebt(int count) {
        debt.sell(count);
    }
}

上記のコードは、外観のコア クラスである FundFacade です。財務管理システムのすべての操作は、このクラスを通じて実装できます。このクラスを通じて、株式、国債、不動産などの財務管理プロジェクトを、処理方法を気にすることなく簡単に操作できるようになります。それはユーザーにとって良いことですよね？

ユーザーの操作を見てみましょう (もちろん、上記のダイアグラム クラスはほとんどの効果を反映しています)。これがユーザーのコード ロジックです:

Investors.java

public class Investors {

    public static void main(String[] args) {
        FundFacade facade = new FundFacade();
        facade.buyAll(120);
        facade.buyStockA(50);
        facade.sellAll(80);
    }
}

ほら、ユーザーは FundFacade に伝えるだけで済みます。何を買うか、何を売るか、いくらで買うか、いくらで売るかというクラスによって目標を達成できます。とても便利です。

銘柄 A のコードを見てください。実際、実質的な変更はありません。これは、アピアランス モードの魅力でもあり、元のサブシステムのコードを変更する必要がなく、必要なことは 1 つだけで、より高いレベルのカプセル化を構築できます。もちろん、ここでは StockA にアクセスするためにいくつかの簡単な変更を加えました。ユーザーに対して透過的である必要があるため、サブシステムをユーザーに対して公開する必要はもうありません。なぜなら、私たちにはすでにプロの外交官、FundFacadeがいるからです。

StockA.java

class StockA {
    private int stockCount = 0;
    void sell(int count){
        stockCount -= count;
        System.out.println("卖了" + count + "支 A 股票");
    }

    void buy(int count){
        stockCount += count;
        System.out.println("买了" + count + "支 A 股票");
    }
    int getStockCount() {
        return stockCount;
    }
}

外観パターンは、簡単に習得して使用できる比較的単純なデザイン パターンです。ここで言いたいのは、外観モードにも一定の制限があるということです。あなたはそれを発見したと思います。

サブシステム上のすべての操作を FundFacade クラスに引き渡すため、FundFacade クラスによる制約を受けます。たとえば、上記の FundFacade クラスは StockB に対する個別の操作を実装していないため、StockB を操作するためのインターフェイスを FundFacade クラスにカプセル化しない限り、StockB のみを操作することはできません。

Appearance Modeの応用

上記の説明では、Appearance Modeの使用方法を知っているだけでなく、Appearance Modeの制限も理解しているため、客観的な観点からAppearance Modeを選択的に使用する必要があります。これは、私の仕事で外観モードを使用する方法の例です。

現在のプロジェクトの上司は、システムに特定のモジュールを実装するように私に依頼しました。これはコアモジュールであるべきだと思います。このモジュールの機能は、フォルダー内のすべてのファイルに機密情報が含まれているかどうかを確認することです。このモジュールには、AC オートマトンのパターン マッチング、圧縮ファイルの完全自動解凍、さまざまな形式のファイル (doc/xls) など、多くの小さなサブモジュールがあります (もちろん、ボスはこれらのサブモジュールが何を行うか気にしません)。 / ppt/zip/eml/rtf/pdf など、ほとんどのファイル形式は基本的にあります）、ログ システムなど。

あなたが完了したい機能が、最初に何をすべきか、次に何をすべきか、次に何をすべきか、次に何をすべきかということを上司に伝えることはできません...

なんてことだ。とても面倒なのでカプセル化してもらえますか？ (もちろん、これらは私の単なる頭の活動です。実際、私は上司に設計プロセスの説明を求めていません)

カプセル化後は、このクラスのこのメソッドを呼び出すように上司に指示するだけでOKです。 。このようにして、上司は内部のロジックを気にする必要はありませんが、何か問題が発生した場合は、それはあなたの責任である必要があります。ははは。 。 。

さて、たわごとはこれで終わりです。上の深刻なパターンの詳細な説明であっても、以下のナンセンスな内容であっても、この記事でデザイン パターンを完全に理解し、学習し、合理的に使用できるようになれば幸いです。

上記は Java デザインパターン - 外観パターンの内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) をご覧ください。