52 | ファサード・モード: インターフェースの使いやすさと汎用性を考慮して、適切なインターフェースの粒度を設計するにはどうすればよいですか?
プロキシ モード、ブリッジ モード、デコレータ モード、アダプタ モード、これら 4 つの構造設計モードを学習しました。今日は、新しい構造モデルであるファサード モデルを学びましょう。ファサードモードの原理と実装は非常に単純で、アプリケーションのシナリオは比較的明確で、主にインターフェイスの設計に使用されます。
普段の仕事にインターフェース開発が含まれている場合、インターフェースの粒度で問題に遭遇したことはありますか?
インターフェースの再利用性 (または汎用性) を確保するために、単一の責任で、インターフェースを可能な限りきめ細かく設計する必要があります。ただし、インターフェイスの粒度が小さすぎると、インターフェイスのユーザーがビジネス関数を開発するときに、n 個を超える粒度の細かいインターフェイスを呼び出して完了する必要があります。発信者は間違いなく、インターフェイスが使いにくいと文句を言うでしょう。
反対に、インターフェースの粒度が大きすぎると、インターフェースは n 個のデータを返し、n 個以上のことを行う必要があり、インターフェースは十分に普遍的ではなく、再利用性は良くありません。インターフェイスは再利用できないため、さまざまな呼び出し元のビジネス ニーズを満たすためにさまざまなインターフェイスを開発する必要があります。これにより、システムのインターフェイスが無限に拡張されます。
では、インターフェイスの再利用性 (汎用性) と使いやすさの間の矛盾をどのように解決するのでしょうか? 今日のファサード モデルの学習を通じて、あなたの心に答えがあると思います。早速、今日から本格的に勉強を始めましょう！
ファサードモードの原理と実現
外観モードとも呼ばれるファサード モード。完全な英語名は Facade Design Pattern です。GoF の本「Design Patterns」では、ファサード パターンは次のように定義されています。
サブシステム内の一連のインターフェイスに統一されたインターフェイスを提供します。Facade パターンは、サブシステムを使いやすくする上位レベルのインターフェイスを定義します。
中国語に翻訳すると、ファサード モードは、サブシステムに統一された一連のインターフェイスを提供し、サブシステムを使いやすくするための一連の高レベル インターフェイスを定義します。
この定義は非常に簡潔なので、さらに説明します。
4 つのインターフェース a、b、c、および d を提供するシステム A があるとします。システム B は、特定のビジネス機能を完了するために、システム A のインターフェース a、b、および d を呼び出す必要があります。ファサード モードを使用して、システム B が直接使用できるように、a、b、および d インターフェースの呼び出しをラップするファサード インターフェース x を提供します。
そんな質問が来るかどうかはわかりません.システムBにa,b,dを直接呼び出させてみましょう.それは大きな問題には思えません.なぜa,b,dをラップするインターフェースxを提供する必要があるのですか.そしてd？この問題について、具体的な例を挙げて説明します。
前述のシステム A がバックエンド サーバーで、システム B がアプリ クライアントであるとします。アプリ クライアントは、バックエンド サーバーによって提供されるインターフェイスを介してデータを取得します。アプリとサーバー間の通信はモバイルネットワークを介しており、ネットワーク通信に多くの時間がかかることがわかっています.アプリの応答速度を向上させるために、アプリとサーバー間のネットワーク通信の数を最小限に抑える必要があります.サーバー。
あるビジネス機能 (あるページに情報を表示するなど) を完了するために、a、b、および d の 3 つのインターフェースを「順番に」呼び出す必要があるとします。これら 3 つのインターフェイスの同時呼び出しをサポートします。
アプリ クライアントの応答速度が比較的遅いことが判明した場合、調査の結果、ネットワーク通信を呼び出すインターフェイスが多すぎることが原因であることがわかりました。この状況に対応して、ファサード モードを使用して、バックエンド サーバーが a、b、および d の 3 つのインターフェイス呼び出しをラップするインターフェイス x を提供できるようにすることができます。アプリのクライアントはインターフェース x を 1 回呼び出すだけで必要なデータをすべて取得できるため、ネットワーク通信の回数が 3 回から 1 回に減り、アプリの応答速度が向上します。
ここに示した例は、パフォーマンスの問題を解決するためのファサード パターンを適用する目的の 1 つにすぎません。実際、さまざまなアプリケーション シナリオでは、ファサード パターンを使用する意図も異なります。次に、ファサード モードのさまざまなアプリケーション シナリオを見てみましょう。
ファサードモードの適用シナリオ例
GoF の定義では、「ファサード モードはサブシステムを使いやすくする」と述べられていますが、実際には、ユーザビリティの問題を解決するだけでなく、他の多くの問題も解決できます。この点について、一般的に使用される 3 つのアプリケーション シナリオをまとめてリストしましたので、これらを参照して、自分のプロジェクトで学習することができます。
また、ファサードパターンの定義における「サブシステム（サブシステム）」も、いろいろな意味で理解できることを強調しておきたい。これは、完全なシステムでも、よりきめ細かいクラスまたはモジュールでもかまいません。この点は、以下の説明にも反映されます。
1. ユーザビリティの問題を解決する
ファサード パターンを使用して、システムの基盤となる実装をカプセル化し、システムの複雑さを隠し、よりシンプルで使いやすい高レベル インターフェイスのセットを提供できます。例えば、Linuxのシステムコール機能は「ファサード」と見なすことができます。これは、Linux オペレーティング システムによって開発者に公開される「特別な」プログラミング インターフェイスのセットであり、基礎となるより基本的な Linux カーネル呼び出しをカプセル化します。別の例として、Linux シェル コマンドは、実際にはファサード モード アプリケーションと見なすことができます。引き続きシステム コールをカプセル化し、より使いやすくシンプルなコマンドを提供し、コマンドを実行することでオペレーティング システムと直接対話できるようにします。
何度も言ってきたように、多くのデザイン原則、アイデア、モデルは相互に関連しており、それらは同じ原則を異なる角度から表現したものです。実際、実装の複雑さを隠し、使いやすいインターフェイスを提供するという観点からすると、ファサード パターンはディミットの法則 (最小知識の原則) とインターフェイス分離の原則に多少似ています。必要なインターフェースを制限しました。さらに、ファサード モードは、前述のカプセル化と抽象化の設計思想にいくぶん似ており、より抽象的なインターフェイスを提供し、基礎となる実装の詳細をカプセル化します。
2.パフォーマンスの問題を解決する
パフォーマンスの問題を解決するためのファサード モードの使用に関しては、先ほど説明しました。複数のインターフェイス呼び出しをファサード インターフェイス呼び出しに置き換えることで、ネットワーク通信コストを削減し、アプリ クライアントの応答速度を向上させます。したがって、この点については、例を挙げません。そのような質問について議論しましょう: コード実装の観点から、ファサードインターフェースと非ファサードインターフェースをどのように編成するのですか?
ファサード インターフェースがあまりない場合は、特別なマーキングなしで非ファサード インターフェースと組み合わせて、通常のインターフェースとして使用することができます。ファサード インターフェースが多数ある場合は、既存のインターフェースの上に別のレイヤーを再抽象化し、ファサード インターフェースを特に配置して、クラスおよびパッケージの命名に関して元のインターフェース レイヤーと区別することができます。ファサード インターフェースが多すぎて、その多くが複数のサブシステムにまたがっている場合は、ファサード インターフェースを新しいサブシステムに入れることができます。
3. 分散トランザクションの問題を解決する
分散トランザクションの問題を解決するためのファサード モードの使用について、例を挙げて説明しましょう。
金融システムには、ユーザーとウォレットという 2 つのビジネス ドメイン モデルがあります。これら 2 つのビジネス ドメイン モデルは両方とも、ユーザーを追加、削除、変更、およびチェックするためのインターフェースや、ウォレットを追加、削除、変更、およびチェックするためのインターフェースなど、一連のインターフェースを公開します。このようなビジネス シナリオがあるとします。ユーザーが登録すると、(データベースの User テーブルに) ユーザーを作成するだけでなく、(データベースの Wallet テーブルに) ユーザーのウォレットも作成します。
このような単純なビジネス要件の場合、ユーザー作成インターフェースとウォレット作成インターフェースを順番に呼び出すことで完了することができます。ただし、ユーザー登録はトランザクションをサポートする必要があります。つまり、ユーザーとウォレットを作成する 2 つの操作が成功するか、両方とも失敗し、一方は成功せず、もう一方は失敗します。
1 つのトランザクションで実行される 2 つのインターフェイス呼び出しをサポートすることは困難であり、これには分散トランザクションの問題が伴います。分散トランザクション フレームワークまたはイベント後補償メカニズムを導入することで解決できますが、コードの実装はより複雑になります。最も簡単な解決策は、データベース トランザクションまたは Spring フレームワーク (Java 言語の場合) によって提供されるトランザクションを使用し、ユーザーの作成とウォレットの作成の 2 つの SQL 操作を 1 つのトランザクションで実行することです。これには、1 つのインターフェースで 2 つの SQL 操作を完了する必要があるため、ファサード モードの考え方から学び、これら 2 つの操作をラップする新しいインターフェースを設計し、新しいインターフェースに 1 つのトランザクションで 2 つの SQL 操作を実行させることができます。
キーレビュー
では、本日の内容は以上です。マスターすべき内容をまとめて復習しましょう。
クラス、モジュール、およびシステム間の「通信」は、通常、インターフェース呼び出しを通じて行われることがわかっています。インターフェイス設計の品質は、クラス、モジュール、およびシステムが使いやすいかどうかに直接影響します。したがって、インターフェイスの設計により多くの時間を費やす必要があります。インターフェイスのデザインを完成させることは、開発作業の半分を完成させることに等しいとよく言います。インターフェイスが適切に設計されている限り、コードはそれほど悪くはありません。
インターフェースの粒度を大きく設計しすぎると、小さすぎると良くありません。大きすぎるとインターフェースが再利用できなくなり、小さすぎるとインターフェースが使いにくくなります。実際の開発では、インターフェースの再利用性と使いやすさは「微妙な」トレードオフを必要とします。この問題に対して、私の基本原則の 1 つは、インターフェースの再利用性を可能な限り維持することですが、特別なケースでは、より使いやすいインターフェースを提供するために、冗長なファサード インターフェースを提供することが許可されています。
インターフェイスの使いやすさの問題を解決することに加えて、ファサード モードは今日、パフォーマンスの問題と分散トランザクションの問題を解決するためにそれを使用する 2 つのアプリケーション シナリオについても話しました。
クラスディスカッション
- アダプターモードとファサードモードの共通点は、使いにくいインターフェースを使いやすいインターフェースに適応させることです。それらの違いを要約してみていただけますか？
- 過去のプロジェクト開発で、不合理なインターフェース要件に遭遇したことがありますか? または、非常に難しいインターフェイスに遭遇したことがありますか? 「tucao」にメッセージを残すことができます。
メッセージを残して私と共有することを歓迎します. 何かを得た場合は、この記事を友達と共有してください.