Ist Passive Ansicht, das Gesetz von Demeter bricht?

Question

Ich versuche zu verstehen, wie Passive Ansicht richtig zu verwenden. Es scheint mir, dass alle Beispiele, die ich sehe Passiv Ansicht bricht das Gesetz von Demeter:

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

Also, was ist eine bessere Umsetzung der Passive View?

Answer 1

Als erstes ist das Gesetz von Demeter, wie die meisten Regeln der Programmierung, eher ein Prinzip oder Leitlinie und es gibt Gelegenheiten, bei denen das Prinzip nicht gilt. Davon abgesehen, ist das Gesetz des Demeter nicht wirklich gilt Passive Ansicht , weil der Grund für das Gesetz ist kein Problem in diesem Fall.

Das Gesetz des Demeter versucht, die Abhängigkeit zu verhindern Verkettungs wie:

objectA.objectB.objectC.DoSomething();

Natürlich, wenn ObjectB Implementierung Änderungen stattdessen verwenden ObjectD dann wird es Objecta die Abhängigkeit durchbrechen und einen Übersetzungsfehler verursachen. Wenn genommen zu einer extremen aufzuwickeln Sie Schrotflinte Chirurgie tun jederzeit die Kette durch eine Implementierung Änderung gestört wird.

Im Fall von Passive Ansicht

• Der Präsentator ist abhängig von einer Schnittstelle so die Umsetzung der Ansicht kann sich ändern, solange die Schnittstelle gleich bleibt.
• Die Sicht in der Regel aussetzt Eigenschaften als verallgemeinerte Datentypen wie Systemtypen und Sammlungen. Auf diese Weise können Sie Änderungen an der Benutzeroberfläche machen, ohne den Moderator zu beeinflussen.
• Um den Moderator die Ansicht als nicht mehr als eine Datenstruktur angezeigt wird, ein Ort zum Abrufen und Dump-Daten. Da die Ansicht ziemlich einfach ist, sollte der Moderator nicht einmal in der Lage sein, die Abhängigkeit Verkettungs zu tun.

So das Beispiel, das Sie gab normalerweise umgesetzt würde:

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

Während die Ansicht wäre so etwas wie:

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

Hope dies verdeutlicht die Dinge ein wenig.

Answer 2

Eine bessere Implementierung wäre eine API zwischen dem Moderator und dem Blick zu haben. Der Presenter würde Push-Daten zu seinem Blick durch ein einziges Verfahren (in der Schnittstelle anzeigen definiert). Die Ansicht würde verwaltet den neuen Eingang nach einiger internen Logik.

Daher muss der Moderator nichts über die Ansicht muß wissen, und das Gesetz des Demeter ist sicher.

Answer 3

Okay, gut, ja, dass hat bricht das Gesetz von Demeter, die im Grunde sagt, dass die Schnittstelle zu einem Objekt nicht die Implementierung des Objekts zeigen soll. Aber dann, die zweite gibt einen verdammt viel von Hinweisen auf die Umsetzung zu.

Ich denke, es ist an der Zeit zu fragen, ob Sie die richtige Schnittstelle im Allgemeinen. Was sind diese Textfelder? Wer setzt sie in der Ansicht? Sollte nicht die Ansicht, das Modell für Daten zu fragen, statt umgekehrt?

Vielleicht müssen Sie das Beobachter-Muster -. Das Modell eine Liste der Interessenten hält und teilt ihnen, wenn ihre internen Zustandsänderungen

---

Ach, , die Passive Ansicht. Habe nicht an, dass seit langer Zeit aussieht. Grundsätzlich sehe ich zwei Teilen: einer von ihnen ist, dass der Controller, indem sie (nicht das Modell) alle Updates fahren, für (nehme ich an) Effizienz er macht die spezifischen Feldmethoden die Felder zu aktualisieren. Dies gilt das Gesetz von Demeter verletzen, das ist doch nur ein „Gesetz“ in einem gewissen metaphorischen Sinne, wie Murphys Gesetz. Es ist in der Regel eine gute Idee, though. In diesem Fall würde ich die Ansicht wiederholen und als Fassade verwenden, um die Aktualisierungen der einzelnen Feld zu wickeln.

Sie müssen nicht die Beobachter-Muster aber, weil jetzt haben Sie den Controller bekommen alle Updates zu machen. Sie fügt hinzu, einige Komplexität und Fehleranfälligkeit des gesamten Code, denn jetzt hve Sie den Controller zu schreiben, um parallel Updates zu machen.