次の問題に最適なパターンを判断できません。
別のサブシステムと対話するクライアント システムがあります。サブシステムは非常に複雑であるため、クライアント システムを簡素化するために 2 つの間のインターフェイスが必要です。これは Facade パターンにぴったりのように思えますが、Adapter パターンも私の問題に適していると思います。
中間のインターフェイスが単純な API 呼び出しを介してサブシステム上の個々のタスクを呼び出す場合、違いはありますか?
次の問題に最適なパターンを判断できません。
別のサブシステムと対話するクライアント システムがあります。サブシステムは非常に複雑であるため、クライアント システムを簡素化するために 2 つの間のインターフェイスが必要です。これは Facade パターンにぴったりのように思えますが、Adapter パターンも私の問題に適していると思います。
中間のインターフェイスが単純な API 呼び出しを介してサブシステム上の個々のタスクを呼び出す場合、違いはありますか?
あなたの説明から、受け入れられているファサードの定義とより一致していますが、何よりも意味論的な議論だと思います。一般に、ファサードはサブシステム全体とのインターフェースの複雑さを軽減しますが、アダプターは既存のインターフェースの微調整や特定のニーズへの呼び出しを目的としています (たとえば、基本的な機能はありますが、戻り値の型が必要なものではありません。等)。
アダプターパターンは、既存のクラスのインターフェイスを、クライアントが操作することを期待する別のインターフェイスに適合させたい場合に使用されます。通常、あるインターフェースのメソッドから別のインターフェースの対応するメソッドへの委譲または変換のみが含まれます。
Facadeは、クライアントが操作できる単純な API セットを公開することで、複雑なシステムを単純化したい場合に使用されます。これには、API 呼び出しの複雑なパターンを単一の API 呼び出しに変換することが含まれます。
あなたのケースは、アダプターよりもファサードが必要なように聞こえます。アダプター パターンだけを実装しても、API の簡素化のメリットは得られません。結局のところ、あなたがそれを何と呼ぶかは問題ではありません。そして、これらのパターンは排他的ではありません。最もメリットが得られるように、両方を組み合わせることができます。
これは明らかに Facade パターンのケースのようです。あなたの目標は、実際の適応ではなく単純化です。
ファサードの定義:
サブシステム内の一連のインターフェイスに統一されたインターフェイスを提供します。Façade は、サブシステムを使いやすくする上位レベルのインターフェイスを定義します。
アダプターの定義:
クラスのインターフェースを、クライアントが期待する別のインターフェースに変換します。Adapter を使用すると、互換性のないインターフェイスのために他の方法では機能できなかったクラスを連携させることができます。
Facade と Adapter の違いは主に意図です。
やりたいことがインターフェイスを簡素化することである場合、Facade を見ています。インターフェイスを他のものとして使用できるように適応させたい場合は、アダプターを使用します。
しかし、本当に、あなたがそれをどのように呼ぶかという問題は何ですか? 私の経験則では、既存のインターフェースを実装している場合、おそらく Adapter インターフェースを使用しています。新しい簡略化されたインターフェイスを作成している場合は、Facade です。
ファサードは、実装ではなくインターフェースを扱います。その目的は、外見は単純に見える単一のインターフェースの背後にある内部の複雑さを隠すことです。