Should I provide access methods / Getter Setters for public / secure components in the form?

Question

If I have a .Net Form with a component / object, such as a text field, that I need to get from the parent or other form, I obviously need to “update” the modifier of this component to an internal or public level variable.

Now, if I were to provide a public variable like int or string, etc. in my form class, I would not think twice about using Getters and (possibly) Setters around this, even if they did nothing else than provide direct access to the variable.

However, the VS developer does not seem to implement such Getters / Setters for those public objects that are components in the form (and therefore do not correspond to good programming practice).

So the question is: To do the “right thing”, do I have to wrap such components or objects of the VS constructor in Getter and / or Setter?

Answer 1

"However, the VS developer does not seem to implement such Getters / Setters for those public objects that are components in the form (and therefore do not comply with good programming practice).

If you mean the controls that you drag into the form, they are marked as private members of the instance and added to the collection of controls. Why should they be different? A form could have forty or fifty controls, it would be somewhat unnecessary and cumbersome to provide a getter / setter for each control on the form. The designer reserves the opportunity to provide delegated access to certain controls through public receivers / setters.

The designer does the right thing here.

Answer 2

The reason for not implementing Getters and Setters for components in the form, I believe, because they would not be "streaming" .Net objects, presumably, should be modified only by the form stream that created them. If you install getter and setters that you potentially open to any thread. Instead, suppose you implement a delegate system where changes to these objects are delegated to the thread that created them and ran there.

Answer 3

This is a classic example of encapsulation in object-oriented design.

A form is an object whose task is to provide the user interface to the user and accept input. The interface between the Form object and other areas of the code should be a data-oriented interface, not an interface that reveals the internal details of the implementation of the Form. The internal workings of the form (i.e. Controls) must remain hidden from any consumer code.

A mature solution is likely to include the following design points:

• Common methods or properties are behavior (show, hide, position) or data-oriented (given data, data, update data).
• All event handlers implemented in the form are wrapped in the appropriate code for thread delegation to ensure compliance with the rules for the execution of the Form stream.
• The controls will be bound to the underlying data structure (where necessary) to reduce code.

And this is not even a mention of meta-developments, such as unit tests.

Answer 4

I always do this, and if you follow an MVP project creating getters / setters for your view components, this will be a design requirement.

I don’t understand what you mean by "not in line with good programming practice." Microsoft is breaking a lot of good programming practices to make it easier to create content in Visual Studio (for the sake of quickly developing applications), and I don't see a lack of getters / settings for controls as evidence of a violation of any such best practices.