またはファサード==ゲートウェイ?
11 に答える
GoF ブックの Facade と、Martin Fowler のゲートウェイへの別の回答のリンクを確認すると、彼らの焦点は反対の方向にあるようです。
Facade は、(1 つ以上の) 外部クライアントに対して、複雑な内部構造のシンプルで統一されたビューを提供します。
ゲートウェイは、アプリケーションの内部に外部リソースのシンプルで統一されたビューを提供します。
この区別により、設計においてどちらがより重要であるかに焦点を当てることができます。
Facade では、外部システムがお客様です。外部インターフェイスを単純にするのであれば、内側に向けて複雑さを追加する方がよいでしょう。
Gateway では、内部システムはお客様です。たとえ外見がより複雑であっても、できる限りの支援をしてください。
これらの2つのパターンは、どちらも何かのラッパーとして機能するという点で非常に似ています。違いはコンテキストにあります。ファサードはサブシステムのグループの上に立っていますが、ゲートウェイは任意の機能の上に立っている可能性があります。この観点から、私にとってファサードはゲートウェイの具体的なケースです(反対ではありません)。
サブシステムの操作が複雑であると考える場合、または複数のサブシステム呼び出しを1つの[メソッド]実行にグループ化する場合に、ファサードが適用されます。ただし、これは必ずしもサブシステムにアクセスできないこと、またはサブシステムが十分に複雑であることを意味するわけではありません。それは単にサブシステムがあることを意味します。
ゲートウェイは、いくつかのものをラップして別の方法で公開したい場合に適用されます。ゲートウェイはサブシステムではなく、比較的複雑な機能をラップしている可能性があります。ゲートウェイは、ファサード、プロキシ、およびその他のパターンの基礎と見なすことができる一般的なパターンです。
明確にするために例がまだ必要な場合:
Facadeは、チェックアカウントサブシステム、クレジットアカウントサブシステム、普通預金サブシステム、およびバックオフィスサブシステムにクエリを実行することで、顧客の信用度を計算できます(GOFブックで同様の例を見たことがあると思います)。
class MortgateFacade {
bool IsCreditWorth(string customerName) {
return !_checkingAccSystem.HasNegativeBalance(customerName) && !_creditAccSystem.HasNegativeCredit(customerName) && !_backOfficeSystem.IsInBlackList(customerName);
}
}
ゲートウェイはデータベーステーブルをクエリし、IDで顧客を返すことができます。(はい、それは簡単です!)
class CustomersGateway {
Customer GetCustomer(int id) {
return _db.ExecuteOne("SELECT TOP 1 FROM CUSTOMERS WHERE CUSTOMER_ID="+id).AsCustomer();
}
}
[明らかにこれは擬似コードです]
Facade の意図は、http://c2.com/cgi/wiki ?FacadePattern で次のように指定されます。
サブシステム内の一連のインターフェイスに統一されたインターフェイスを提供します。Facade は、サブシステムを使いやすくする上位レベルのインターフェイスを定義します。これを使用して、多数の複雑なオブジェクトの相互作用を単一のインターフェースに簡素化できます。
ここでの焦点は、複雑さを隠すインターフェイスを設計することです。重要なアイデアは、複数のきめの細かいインタラクションを 1 つのより使いやすいインタラクションに隠すことだと思います。したがって、Facade の焦点はクライアントに面することです。
ゲートウェイ パターンは元の GOF パターンの 1 つではありません。私はそれをエンタープライズ統合パターン、つまりファサードよりもかなり高いレベルにあると考えています。Fowler の定義を参照してください。
ゲートウェイは主に、インターフェースの複雑さではなく、技術的な複雑さを隠すもの、つまりメインフレームや外部システムへの接続の詳細を隠すものだと考えています。実際、ゲートウェイがリクエスト ルーターのようなものになることを期待することがよくあります。おそらく、リクエストの詳細に基づいて異なるバックエンド システムを選択することさえあります。ですから、Gateway はゲートウェイとなるものに焦点を当てていると思います。
明らかに、非公式に言えば、ゲートウェイは詳細を隠すという点でファサードですが、GOF ファサードとファウラー ゲートウェイを実装すると、まったく異なることを行うことになると思います。
ファウラーの本からの直接の引用は次のとおりです。
Facade はより複雑な API を簡素化しますが、通常は、一般的な使用のためにサービスの作成者によって行われます。ゲートウェイは、特定の用途のためにクライアントによって作成されます。さらに、Facade は、それがカバーするものとは異なるインターフェイスを常に暗示しますが、Gateway はラップされた Facade を完全にコピーして、代替またはテストの目的で使用することができます。
【第18章】
これはやや単純化されているかもしれませんが、これが私の見解です。
- Facade パターンを使用する場合、他のユーザーがアプリケーションと対話するために使用できるインターフェイスを提供します。例:複数の「モジュール」を持つアプリケーションを実装しました。「モジュール」へのアクセスを容易にするために、モジュールとの対話を容易にする Facade を作成します... 単一の連絡先です。
- ゲートウェイ パターンを使用する場合、使用する外部パーツをカプセル化します。例:ロギングを使用したいが、特定のロギング フレームワークにバインドしたくない場合は、使用する機能を定義するゲートウェイを定義し、ゲートウェイにロギング フレームワークとの対話を処理させることができます。使用する。これにより、将来のロギング フレームワークの変更が容易になります。
ゲートウェイはファサードの特定のケースだと思います-外部システム上のファサードです。
簡単に言えば、Facade はデザイン パターンで、Gateway はアーキテクチャ パターンです。
たとえば、Application Gateway はインフラストラクチャ アーキテクチャ パターンです。ノードは DMZ に常駐し、アプリケーション ゲートウェイにしか接続できない外部クライアントから内部ノードを隔離します。
アーキテクチャ パターンについて考えるときは、ノードについて考えてください。デザイン パターンについて考えるときは、クラス/オブジェクトについて考えてください。
ノードは、デバイス - ハードウェアとシステム ソフトウェア - OS、プラットフォーム/フレームワークなどの抽象化です。システム ソフトウェアはデバイスに「割り当て」られます。ノードは、デバイスとシステム ソフトウェアの両方を「カプセル化」し、アーキテクチャを構成する他のノードに関連付けられます。
ゲートウェイは、サーバー ノードをクライアント ノードから隔離するノードです。クライアント ノードはサーバー ノードに直接接続できません。ゲートウェイは接続を受信し、宛先ノードへの接続を確立します。
単一のオブジェクトのようにオブジェクトのグラフを操作するために使用されるファサードと、2 つの異なるモジュール/システムを接続するためのゲートウェイ。
あなたの質問に答えるために、Facade==Gateway とは言いませんが、Facade≈Gateway とは言えません。つまり、それらはほぼ等しいということですが、上記のさまざまな意見に基づいて、それらがどのように異なるかは明らかではありません.
一般的に、デザイン パターンと用語の重要な要素の 1 つは、アイデアをより簡単に伝えるためのものであることを覚えておく必要があります。そうは言っても、常にファサードの観点から話すと、それが最も頻繁に使用される用語であるため、理解される可能性が高くなります.
私は多くのパターンを Proxy パターンの特殊なケースとして考える傾向があり、具体的にどのパターンかはあまり気にしません。
すなわち:
Facade は、一連の複雑なクラスへの単純なプロキシです。
アダプターは、現時点で必要なものとして、互換性のないインターフェースを持つシステムの一部へのプロキシです
等...
「ゲートウェイパターン」のGoogle検索で見つけたものから判断すると、ゲートウェイ==プロキシのようです:D