Sollte ich Accessor-Methoden/Getter Setter für öffentliche/geschützte Komponenten in einem Formular bereitstellen?

Question

Wenn ich .Net Form mit einer Komponente/Objekt wie einem Textfeld habe, auf das ich von einem Eltern oder anderen Formular zugreifen muss, muss ich natürlich den Modifikator zu dieser Komponente auf eine interne oder öffentliche Variable "upgraden".

Nun, wenn ich eine öffentliche Variable eines int oder string type etc. in meiner Formularklasse bereitstellen würde, würde ich nicht zweimal darüber nachdenken, Getters und (vielleicht) Setter darum zu verwenden, auch wenn sie nichts getan haben andere als den direkten Zugriff auf die Variable.

Der VS-Designer scheint jedoch solche Getter/Setter nicht für solche öffentlichen Objekte zu implementieren, bei denen es sich um Komponenten in einem Formular handelt (und entspricht daher nicht der guten Programmierpraxis).

So ist die Frage; Um das "Richtige" zu tun, sollte ich solche VS-Designer-Komponenten oder -Objekte in einen Getter und/oder Setter einpacken?

Answer 1

„jedoch die VS-Designer scheinen nicht so Getter zu implementieren/Setters für die öffentlichen Objekte, die Komponenten auf einem Formular sind (und deshalb nicht mit gutem Programmierstil nicht entspricht).“

Wenn Sie meinen die Steuerelemente, die Sie auf das Formular ziehen und dort ablegen. Diese Elemente werden als private Instanzmitglieder markiert und zur Controls-Sammlung des Formulars hinzugefügt. Warum sollten sie anders sein? Ein Formular könnte vierzig oder fünfzig Steuerelemente haben, es wäre etwas unnötig und unhandlich, einen Getter/Setter für jedes Steuerelement auf dem Formular bereitzustellen. Der Designer überlässt Ihnen den delegierten Zugriff auf bestimmte Steuerelemente über öffentliche Getter/Setter.

Der Designer macht hier das Richtige.

Answer 2

Ich mache das immer, und wenn Sie ein MVP-Design folgen, wäre das Erstellen von Getter/Setter für Ihre Ansichtskomponenten eine Design-Anforderung.

Ich verstehe nicht, was Sie meinen, "entspricht nicht der guten Programmierpraxis". Microsoft verletzt viel von guten Programmierpraktiken, um es einfacher zu machen, Sachen in Visual Studio zu erstellen (aus Gründen der schnellen App-Entwicklung) und ich sehe nicht das Fehlen von Getter/Setter für Kontrollen als Beweis der Verletzung dieser Best Practices .

Answer 3

Der Grund für die Implementierung von Getters und Setter für Komponenten in einem Formular glaube ich ist, weil sie nicht "Thread Safe" sind. Net-Objekte sollen nur durch den Formular-Thread, der sie erstellt, geändert werden auf Getter und Setter können Sie es für jeden Thread öffnen. Stattdessen sollten Sie ein Delegatensystem implementieren, bei dem Änderungen an diesen Objekten an den Thread delegiert werden, der sie erstellt hat und dort ausgeführt wurde.

Answer 4

Dies ist ein klassisches Beispiel für die Kapselung in objektorientiertem Design.

Ein Formular ist ein Objekt, dessen Aufgabe es ist, dem Benutzer die Benutzeroberfläche zu präsentieren und Eingaben zu akzeptieren. Die Schnittstelle zwischen dem Formularobjekt und anderen Bereichen des Codes sollte eine datenorientierte Schnittstelle sein, keine Schnittstelle, die die inneren Implementierungsdetails des Formulars freilegt. Die inneren Funktionen des Formulars (dh die Steuerelemente) sollten vor jedem konsumierenden Code verborgen bleiben.

Eine ausgereifte Lösung wäre wahrscheinlich die folgenden Design Punkte beinhaltet:

• öffentliche Methoden oder Eigenschaften Verhalten sind (zeigen, verstecken, Position) oder datenorientierten (Einstelldaten, erhalten Daten, Aktualisierungsdaten).
• Alle vom Formular implementierten Ereignisbehandlungsroutinen werden in entsprechenden Threaddelegationscode eingeschlossen, um die Ausführungsregeln für Formularthreads zu erzwingen.
• Die Steuerelemente selbst sind datengebunden an die zugrunde liegende Datenstruktur (wo dies angebracht ist), um den Code zu reduzieren.

Und das ist nicht zu erwähnen Meta-Entwicklung Dinge wie Komponententests.