5年働いていますが、ファサードモデルがまだわかりません。

が ファサード パターン # を共有します。デザインパターン。 ＃＃。 適切なライフ ストーリーと実際のプロジェクト シナリオを使用してデザイン パターンを伝えます最後に、このデザイン パターンを 1 つの文で要約します。

すべての開発友人は、バックエンド開発が通常: # であることを知っています。 ##controller---servie---dao/mapper/repository

今日はLao Tianがファサードモードをご紹介します。

ファサード パターンの概要

ファサード パターン (ファサード パターン ) は、外観とも呼ばれます。パターン は、サブシステム内のインターフェイスのグループにアクセスするための統合インターフェイスを提供します。その主な特徴は、サブシステムを使いやすくするための高レベルのインターフェイスを定義しており、構造設計パターンに属していることです。 ＃＃＃＃＃＃英語：＃＃＃

サブシステム内の一連のインターフェイスに統一インターフェイスを提供します。Facade は、サブシステムを使いやすくする高レベルのインターフェイスを定義します。

実際、日常のコーディング作業では、彼らは皆、意図的か非意図的かに関わらず、ファサードのパターンを多用しています。高レベルのモジュールが複数のサブシステム (3 つ以上のクラス オブジェクト) をスケジュールする必要がある場合は常に、これらのサブシステムをカプセル化する新しいクラスを意識的に作成し、高レベルのモジュールがこれらのサブシステムの関数をより簡単に間接的に呼び出せるように合理化されたインターフェイスを提供します。サブシステム。

実例

実例では、ファサード モデルに関する事例が非常にたくさんあります。

ケース 1: 用事を処理するために銀行に行くと、フロントデスクがあなたを迎えてくれます。 , そのため、あちこち歩き回ってどこにでも行く必要はありません。対応するビジネス窓口を見つけてください。このフロントスタッフがファサードモデルに相当します。

ケース 2: 家を建てるときに、請負業者がいない場合は、セメント工、電気技師、装飾業者などを自分で探さなければなりません。しかし、業者に依頼すれば、これらの作業を行う必要はなく、配線を直すために電気技師が必要であることを業者に直接伝えることができます。この請負業者はファサード モデルとして理解できます。

ケース 3: バックエンドによって開発された controller はファサード モードとしても理解できます。たとえば、ユーザー アカウント情報を取得するには、まず UserService をチェックして取得します。ユーザー情報を確認し、UserAccountService ユーザー アカウント情報を確認します。

ファサード モードに適用できるシナリオ

ソフトウェア システムでは、ファサード モードは次のアプリケーション シナリオに適しています。

• 複雑なモジュールまたはサブシステムへの外部アクセスのためのシンプルなインターフェイスを提供します。
• サブシステムの独立性を高めたい場合。
• 避けられない一時的な理由により、サブシステムにバグやパフォーマンス関連の問題が発生する可能性がある場合、ファサード モードを通じて高レベルのインターフェイスを提供して、クライアントとクライアント間の直接の対話を分離できます。コード汚染を防ぎます。

ファサード モードの一般的な記述方法

単純なファサードを実装するには引き続きコードを使用しますモード、なぜならデモから始めるのが一番好きなからです。

ビジネス シナリオ: 次に、3 つのサービスのそれぞれのメソッドを呼び出す必要があります:

public class ServiceA {
    public void doA(){
        System.out.println("do ServiceA");
    }
}
public class ServiceB {
    public void doB(){
        System.out.println("do ServiceB");
    }
}

public class ServiceC {
    public void doC(){
        System.out.println("do ServiceC");
    }
}

ファサード モードが導入されていない場合、クライアントは次のように呼び出します:

public class Client {
    public static void main(String[] args) {
        ServiceA serviceA=new ServiceA();
        ServiceB serviceB=new ServiceB();
        ServiceC serviceC=new ServiceC();

        serviceA.doA();
        serviceB.doB();
        serviceC.doC();
    }
}

Every Second 次に、クライアント自体が多くのサービス オブジェクトを作成する必要がありますが、多くのサービスが関与する場合、このコードは非常に厄介ではないでしょうか。繰り返しのコードが多くなります。

実行結果

do ServiceA
do ServiceB
do ServiceC

ファサードモードを追加しましょう:

public class Facade {
    //是不是很像我们controller里注入各种service?
    private ServiceA serviceA = new ServiceA();
    private ServiceB serviceB = new ServiceB();
    private ServiceC serviceC = new ServiceC();

    public void doA() {
        serviceA.doA();
    }

    public void doB() {
        serviceB.doB();
    }

    public void doC() {
        serviceC.doC();
    }
}

クライアントは次のようになります:

public class Client {
    public static void main(String[] args) {
        //轻轻松松的搞定，只需要创建门面这个对象即可
        Facade facade=new Facade();
        facade.doA();
        facade.doB();
        facade.doC();
    }
}

実行結果:

do ServiceA
do ServiceB
do ServiceC

#ファサード パターン UML 図

## 結合この UML 図を使用すると、銀行のフロント デスク担当者や請負業者のケースを検討するときに、ファサード パターンを理解しやすくなります。

ファサード モードのロール上の図からわかるように、ファサード モードには主に 2 つのロールが含まれています。

• 外観ロール (ファサード): ファサード ロールとも呼ばれ、システムの統合された外部インターフェイスです。
• サブシステム ロール (Service): 同時に 1 つ以上の Service が存在できます。各 Service は個別のクラスではなく、クラスのコレクションです。 Service は Facade の存在を知りません。サービスにとって、Facade は単なる別のクライアントです (つまり、Facade は ## です) #ServiceA、ServiceB、ServiceC 透過的)。

#ファサードパターンの拡張

#メリット

## システムの相互依存性を軽減する 考えてみてください、ファサードモードを使わないと、外部からのアクセスは直接サブシステムに入り、あなたが死ねば私も死ぬ、あなたが生きれば私も生きる、という強い結合関係が生まれます。強い依存関係はシステム設計の結果です。受け入れられません。ファサード パターンの出現により、この問題は非常にうまく解決されます。すべての依存関係はファサード オブジェクトにあり、サブシステムとは何の関係もありません。 #● 柔軟性の向上 依存性が減り、自然に柔軟性が高まります。サブシステムが内部的にどのように変化しても、ファサード オブジェクトに影響を与えない限り、自由に移動できます。

● 提高安全性 　　想让你访问子系统的哪些业务就开通哪些逻辑，不在门面上开通的方法，你休想访问到 。

缺点

• 当增加子系统和扩展子系统行为时，可能容易带来未知风险。
• 不符合开闭原则。
• 某些情况下，可能违背单一职责原则。

大神们是如何使用的

在Spring中也是有大量使用到门面模式，比如说

org.springframework.jdbc.support.JdbcUtils

再来看看其中的方法

public static void closeConnection(@Nullable Connection con) {
    con.close();
}
public static Object extractDatabaseMetaData(DataSource dataSource, DatabaseMetaDataCallback action)
   throws MetaDataAccessException {
    Connection con = null;
  try {
   con = DataSourceUtils.getConnection(dataSource);
   DatabaseMetaData metaData = con.getMetaData();
   if (metaData == null) {
      //.....
   }
   return action.processMetaData(metaData);
  }
}
......

都是给我封装好了方法，对于我们开发者来说，我只面向JdbcUtils这一个类就好了，我不用去管Connection、ResultSet等是怎么创建的，需要的时候，我调用JdbcUtils的对应方法即可获得对应的对象。

在Mybatis中也是用到了门面模式，比如：

org.apache.ibatis.session.Configuration

在Configuration中以new开头的方法，比如：

public Executor newExecutor(Transaction transaction) {
    return newExecutor(transaction, defaultExecutorType);
}
public MetaObject newMetaObject(Object object) {
    return MetaObject.forObject(object, objectFactory, objectWrapperFactory, reflectorFactory);
}

public ParameterHandler newParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql) {
    ...
    return parameterHandler;
}

public ResultSetHandler newResultSetHandler(Executor executor, MappedStatement mappedStatement, RowBounds rowBounds, ParameterHandler parameterHandler,
      ResultHandler resultHandler, BoundSql boundSql) {
   ...
    return resultSetHandler;
}

public StatementHandler newStatementHandler(Executor executor, MappedStatement mappedStatement）{
   ...
}

对于调用这些方法的地方，他并不知道是怎么new出来的对象，只管使用就行了。

在Tomcat中也有门面模式，比如：

org.apache.catalina.connector.RequestFacade

从名字就知道它用了门面模式。它封装了非常多的request操作，也整合了很多servlet-api以外的内容，给用户使用提供了很大便捷。同样，Tomcat针对Response和Session也封装了对应的ResponseFacade类和StandardSessionFacade类，感兴趣的小伙伴可以深入了解一下。

PS：基本上所有以Facade结尾的类，都是使用到了门面模式。

参考: Tom のデザイン パターン コース

概要

わかりました。ファサード モードについてたくさん共有しました。この記事を読んで、ファサード モードが実際には非常にシンプルであると思いましたか?また、それが仕事で使用できるかどうかを検討することもできます。面接で自慢すること。