Dois-je fournir des méthodes d'accès / Getter Setters pour les composants publics/protégés sur un formulaire ?

Question

Si j'ai un formulaire .Net avec un composant/objet tel qu'une zone de texte auquel je dois accéder depuis un parent ou un autre formulaire, je dois évidemment "mettre à niveau" le modificateur de ce composant vers une variable de niveau interne ou public.

Maintenant, si je fournissais une variable publique de type int ou string, etc.dans ma classe de formulaire, je n'hésiterais pas à utiliser des Getters et (peut-être) des Setters à ce sujet, même s'ils ne faisaient rien d'autre que de fournir un accès direct à la variable.

Cependant, le concepteur VS ne semble pas implémenter de tels Getters/Setters pour les objets publics qui sont des composants d'un formulaire (et n'est donc pas conforme aux bonnes pratiques de programmation).

Donc, la question est :Afin de faire la « bonne chose », dois-je envelopper ces composants ou objets du concepteur VS dans un Getter et/ou un Setter ?

Answer 1

"Cependant, le concepteur VS ne semble pas implémenter de tels Getters/Setters pour les objets publics qui sont des composants d'un formulaire (et n'est donc pas conforme aux bonnes pratiques de programmation)."

Si vous parlez des contrôles que vous faites glisser et déposez sur le formulaire, ceux-ci sont marqués comme membres d’instance privés et sont ajoutés à la collection Controls du formulaire.Pourquoi en seraient-ils autrement ?Un formulaire peut avoir quarante ou cinquante contrôles, il serait quelque peu inutile et lourd de fournir un getter/setter pour chaque contrôle du formulaire.Le concepteur vous laisse le soin de fournir un accès délégué à des contrôles spécifiques via des getter/setters publics.

Le designer fait ce qu'il faut ici.

Answer 2

La raison pour laquelle je n'implémente pas les Getters et les Setters pour les composants sur un formulaire est, je crois, parce qu'ils ne seraient pas "Thread Safe". Les objets Net sont censés être modifiés uniquement par le thread de formulaire qui les a créés, si vous utilisez des getter et des setters. vous l'ouvrez potentiellement pour n'importe quel fil.Au lieu de cela, vous supposez implémenter un système de délégation dans lequel les modifications apportées à ces objets sont déléguées au thread qui les a créés et exécutés là-bas.

Answer 3

Il s’agit d’un exemple classique d’encapsulation dans la conception orientée objet.

Un formulaire est un objet dont la responsabilité est de présenter l'interface utilisateur à l'utilisateur et d'accepter les entrées.L'interface entre l'objet Form et d'autres zones du code doit être une interface orientée données, et non une interface qui expose les détails d'implémentation internes du Form.Le fonctionnement interne du formulaire (c'est-à-dire les contrôles) doit rester caché à tout code consommateur.

Une solution mature impliquerait probablement les points de conception suivants :

• Les méthodes ou propriétés publiques sont comportementales (afficher, masquer, position) ou orientées données (définir des données, obtenir des données, mettre à jour des données).
• Tous les gestionnaires d'événements implémentés par le formulaire sont enveloppés dans un code de délégation de thread approprié pour appliquer les règles d'exécution des threads du formulaire.
• Les contrôles eux-mêmes seraient liés aux données à la structure de données sous-jacente (le cas échéant) pour réduire le code.

Et cela ne parle même pas des éléments de méta-développement comme les tests unitaires.

Answer 4

Je fais toujours cela, et si vous suivez une conception MVP, la création de getter/setters pour vos composants de vue serait une exigence de conception.

Je ne comprends pas ce que vous entendez par "n'est pas conforme aux bonnes pratiques de programmation".Microsoft viole beaucoup de bonnes pratiques de programmation pour faciliter la création de contenus sur Visual Studio (dans un souci de développement rapide d'applications) et je ne vois pas le manque de getters/setters pour les contrôles comme une preuve de violation de ces meilleures pratiques.