0

私たちのアプリケーション（C＃）では、ファサードはコアのAPIとして使用されます。ファサードは、アプリ自体がコアで処理を行うために使用されます。それを知って、ここに私の質問があります：

  1. ファサードがラップするコアオブジェクトの1つに、再帰ビットが含まれていると仮定しますか？たとえば、ファサードはツリーから「GetX」を提供し、各ノードはそのサブツリーからGetXを取得する必要があります。このノードはファサードの「GetX」を使用する必要がありますか？
  2. ファサードはコアオブジェクトをアプリケーションに公開する必要がありますか？たとえば、ユーザーはツリーの構築、ノードの追加、ツリーの印刷、ツリーの計算などを行います。アプリケーションはツリーオブジェクトを使用する必要がありますか、それともファサードにツリーの作成、保存、プリンティングなどを依頼する必要がありますか？

ありがとう。

4

3 に答える 3

1

質問1に関して： 他の人が言ったように。いいえ。代わりに、この操作に別のインターフェイスを使用することを検討し (インターフェイス分離の原則がここで適用される可能性がありますか?)、最初に Facade を介してそのインターフェイスの操作にアクセスします。再帰時に、内部インターフェイスを直接使用できます。これにより、関心がいくらか分離される可能性がありますが、必要に応じて後で実装を簡単に変更することもできます。

再帰自体が実装の詳細であり、ファサードが何も知る必要がないかのように思えます。同様に、ファサードは、実装するアルゴリズムが知る必要のないものです (つまり、ファサードを介して繰り返さないでください)。

質問 2 について:これについてもインターフェイスを定義するのはどうですか? たとえばITree、ITreeNode、 などで、これらを操作する Facade の操作を含めます。次に、実装にこれらのインターフェースを実装させ、コア オブジェクトを公開することなく、ファサードの外部で必要なオブジェクトを提供します。

于 2012-08-16T11:01:12.433 に答える
1

ファサードは、より大きなコード本体への単純化されたインターフェースを提供するオブジェクトです。

したがって、シンプルにしてください。

  1. いいえ。 Facade をそれ自体にカプセル化します。ツリーを取得するためのプライベートな実装があると仮定します。これを内部で使用し、入力されたオブジェクトを返すパブリック メソッドのみを公開します (ポイント 2 を参照)。

  2. いいえ。ファサードはすべてを行う必要があります。それ以外の場合は、ファサードを作成する意味がほとんどありません。ファサード メソッド内で使用できる DTO を作成したい場合がありますが、コア オブジェクトは公開しないでください。

于 2012-08-16T05:38:22.080 に答える
0

ファサードは通常、コアをラップし、特定の機能セットへのアクセスを提供します。

  1. 一貫性のためにそれを行いたいかもしれませんが、ファサードによって提供される抽象化を保持する別の簡単な方法があれば、それがより良いでしょう。

  2. コアコードを公開する必要はありません (ファサードの目的に反することになります)。機能を追加したい場合は、ファサード内のコア関数を呼び出す関数をファサードに追加します。

于 2012-08-16T05:40:01.647 に答える