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

Question

Wenn ich ein .NET-Formular mit einer Komponente/einem Objekt wie einem Textfeld habe, auf das ich von einem übergeordneten oder einem anderen Formular aus zugreifen muss, muss ich natürlich den Modifikator dieser Komponente auf eine Variable auf interner oder öffentlicher Ebene „aktualisieren“.

Wenn ich nun eine öffentliche Variable vom Typ int oder string usw. bereitstellen würde.In meiner Formularklasse würde ich nicht zweimal darüber nachdenken, hierfür Getter und (vielleicht) Setter zu verwenden, selbst wenn sie nichts anderes tun würden, als direkten Zugriff auf die Variable bereitzustellen.

Allerdings scheint der VS-Designer solche Getter/Setter nicht für die öffentlichen Objekte zu implementieren, die Komponenten in einem Formular sind (und entspricht daher nicht der guten Programmierpraxis).

Die Frage ist also;Um das „Richtige“ zu tun, sollte ich solche VS-Designer-Komponenten oder -Objekte in einen Getter und/oder Setter einschließen?

Answer 1

"Allerdings scheint der VS-Designer solche Getter/Setter nicht für die öffentlichen Objekte zu implementieren, die Komponenten in einem Formular sind (und entspricht daher nicht der guten Programmierpraxis)."

Wenn Sie die Steuerelemente meinen, die Sie per Drag-and-Drop auf das Formular ziehen, werden diese als private Instanzmitglieder markiert und der 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, für jedes Steuerelement im Formular einen Getter/Setter bereitzustellen.Der Designer überlässt es Ihnen, über öffentliche Getter/Setter delegierten Zugriff auf bestimmte Steuerelemente bereitzustellen.

Hier macht der Designer das Richtige.

Answer 2

Der Grund dafür, dass Getter und Setter für Komponenten in einem Formular nicht implementiert werden, liegt meines Erachtens darin, dass sie nicht „Thread-sicher“ wären. NET-Objekte sollen nur von dem Formularthread geändert werden, der sie erstellt hat, wenn Sie Getter und Setter einsetzen Sie öffnen es möglicherweise für jeden Thread.Stattdessen sollten Sie ein Delegatensystem implementieren, bei dem Änderungen an diesen Objekten an den Thread delegiert werden, der sie erstellt und dort ausgeführt hat.

Answer 3

Dies ist ein klassisches Beispiel für Kapselung im objektorientierten Design.

Ein Formular ist ein Objekt, dessen Aufgabe darin besteht, dem Benutzer die Benutzeroberfläche anzuzeigen und Eingaben zu akzeptieren.Die Schnittstelle zwischen dem Form-Objekt und anderen Bereichen des Codes sollte eine datenorientierte Schnittstelle sein, keine Schnittstelle, die die inneren Implementierungsdetails des Formulars offenlegt.Das Innenleben des Formulars (d. h. die Steuerelemente) sollte vor jeglichem konsumierenden Code verborgen bleiben.

Eine ausgereifte Lösung würde wahrscheinlich die folgenden Designpunkte beinhalten:

• Öffentliche Methoden oder Eigenschaften sind verhaltensorientiert (Anzeigen, Ausblenden, Positionieren) oder datenorientiert (Daten festlegen, Daten abrufen, Daten aktualisieren).
• Alle vom Formular implementierten Ereignishandler sind in den entsprechenden Thread-Delegierungscode eingebettet, um die Thread-Ausführungsregeln des Formulars durchzusetzen.
• Die Steuerelemente selbst wären (sofern zutreffend) datengebunden an die zugrunde liegende Datenstruktur, um den Code zu reduzieren.

Und dabei sind Meta-Entwicklungsdinge wie Unit-Tests noch nicht einmal erwähnt.

Answer 4

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

Ich verstehe nicht, was Sie mit „entspricht nicht der guten Programmierpraxis“ meinen.Microsoft verstößt gegen eine Menge von guten Programmierpraktiken, um das Erstellen von Dingen in Visual Studio zu erleichtern (im Interesse einer schnellen App-Entwicklung), und ich sehe das Fehlen von Gettern/Settern für Steuerelemente nicht als Beweis für einen Verstoß gegen solche Best Practices.