3

パッシブビューを正しく使用する方法を理解しようとしています。パッシブビューで見るすべての例は、デメテルの法則に違反しているように思われます。

//In the presenter code
myview.mytextfield.text = "whatever";

では、パッシブビューのより良い実装は何ですか？

4

3 に答える 3

4

まず、デメテルの法則は、プログラミングのほとんどのルールと同様に、原則またはガイドラインのようなものであり、原則が適用されない場合があります。そうは言っても、デメテルの法則はパッシブ ビューには実際には適用されません。この場合、法則の理由は問題ではないからです。

デメテルの法則は、次のような依存関係の連鎖を防止しようとしています。

objectA.objectB.objectC.DoSomething();

明らかに、objectB の実装が代わりに objectD を使用するように変更された場合、objectA の依存関係が壊れ、コンパイル エラーが発生します。極端な場合は、実装の変更によってチェーンが妨げられるたびに、散弾銃の手術を行うことになります。

パッシブビューの場合

  • プレゼンターはインターフェイスに依存するため、インターフェイスが同じである限り、ビューの実装は変更できます。
  • ビューは通常、システム タイプやコレクションなどの一般化されたデータ タイプとしてプロパティを公開します。これにより、プレゼンターに影響を与えずに UI を変更できます。
  • プレゼンターにとって、ビューはデータ構造、つまりデータを取得してダンプする場所に過ぎないように見えます。ビューは非常に単純なので、プレゼンターは依存関係の連鎖を行うことさえできないはずです。

したがって、あなたが与えた例は通常実装されます：

//from presenter
view.MeaningfulName = "data";

ビューは次のようになりますが、

//from view
public string MeaninfulName
{
    get
    {
        return someControl.text;
    }
    set
    {
        someControl.text = value;
    }

これが物事を少し明確にすることを願っています。

于 2009-06-18T20:36:13.303 に答える
1

さて、そうです、それはデメテルの法則を破ります。それは基本的に、オブジェクトへのインターフェースがオブジェクトの実装を明らかにするべきではないと言っています。しかし、2つ目は、実装にも多くのヒントを与えます。

一般的に正しいインターフェースを持っているかどうかを尋ねる時が来たと思います。これらのテキストフィールドは何ですか？誰がそれらをビューに設定していますか？ビューは、その逆ではなく、モデルにデータを要求するべきではありませんか？

おそらく、オブザーバーパターンが必要です。モデルは関係者のリストを保持し、内部状態が変化したときに通知します。

ああ、そのパッシブビュー。長い間それを見ていませんでした。基本的に、2つの部分があります。1つは、コントローラー（モデルではない）にすべての更新を駆動させることで、（おそらく）効率のために、特定のフィールドメソッドを公開してそれらのフィールドを更新することです。これは、デメテルの法則に違反します。これは、結局のところ、マーフィーの法則のように、比喩的な意味での「法則」にすぎません。ただし、通常はそれをお勧めします。この場合、ビューをやり直して、個々のフィールドへの更新をラップするためのファサードとして使用します。

ただし、コントローラーがすべての更新を行うようになったため、オブザーバーパターンは必要ありません。並列更新を行うためにコントローラーを作成する必要があるため、コード全体に複雑さとエラーが発生しやすくなります。

于 2009-05-26T17:37:01.743 に答える
1

より良い実装は、プレゼンターとビューの間に API を持つことです。プレゼンターは、(ビューのインターフェイスで定義された) 単一のメソッドを介してビューにデータをプッシュします。ビューは、何らかの内部ロジックに従って新しい入力を管理します。

したがって、プレゼンターはビューについて何も知る必要がなく、デメテルの法則は安全です。

于 2009-05-26T18:57:40.253 に答える