Should I provide accessor methods / Getter Setters for public/protected components on a form?

If I have .Net Form with a component/object such as a textbox that I need to access from a parent or other form I obviously need to "upgrade" the modifier to this component to an Internal or Public level variable.

Now, if I were providing a public variable of an int or string type etc. in my form class I wouldn't think twice about using Getters and (maybe) Setters around this, even if they didn't do anything other than provide direct access to the variable.

However, the VS designer doesn't seem to implement such Getters/Setters for those public objects that are components on a form (and therefore does not comply with good programming practice).

So, the question is; In order to do the "right thing" should I wrap such VS designer components or objects in a Getter and/or Setter??

From stackoverflow Calanus

• I always do that, and if you ARE following an MVP design creating getter/setters for your view components would be a design requirement.

  I do not understand what you mean by "does not comply with good programming practice". Microsoft violates a lot of good programming practices to make it easier to create stuff on Visual Studio (for the sake of rapid app development) and I do not see the lack of getters/setters for controls as evidence of violating any such best practices.

  From Jon Limjap

• The reason for not implementing Getters and Setters for components on a form I believe is cause they wouldn't be "Thread Safe" .Net objects are suppose to be only modified by the form thread that created them, If you put on getter and setters you are potentially opening it up for any thread. Instead your suppose to implement a delegate system where changes to these objects are delegated to the thread that created them and ran there.

  From Tanerax

• "However, the VS designer doesn't seem to implement such Getters/Setters for those public objects that are components on a form (and therefore does not comply with good programming practice)."

  If you mean the controls you're dragging and dropping onto the form, these are marked as private instance members and are added to the form's Controls collection. Why would they be otherwise? A form could have forty or fifty controls, it'd be somewhat unnecessary and unwieldy to provide a getter/setter for every control on the form. The designer leaves it up to you to provide delegated access to specific controls via public getter/setters.

  The designer does the right thing here.

  From Kev

• @Tanerax

  So surely your answer suggests that we should implement Getters/Setters so that we can ensure that anything that calls the components are on the same thread??

  If I don't implement the getters/setters but the components' modifer is public then surely that doesn't automatically make it thread safe as the component could still be called from another thread?

  From Calanus

• @Calanus,

  Kind of yes, they wouldn't just be a run of the mill get/set but I guess you could implement a get/set utilizing the proper thread safe invoking steps. But most of the time I usually just create a method to handle form updates that are dealt outside of the form.

  From Tanerax

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

  A Form is an object whose responsibility is to present UI 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 which exposes the inner implementation details of the Form. The inner workings of the Form (ie, the controls) should remain hidden from any consuming code.

  A mature solution would probably involve the following design points:

  • Public methods or properties are behavior (show, hide, position) or data-oriented (set data, get data, update data).
  • All event handlers implemented by the Form are wrapped in appropriate thread delegation code to enforce Form thread-execution rules.
  • Controls themselves would be data-bound to the underlying data structure (where appropriate) to reduce code.

  And that's not even mentioning meta-development things like unit tests.

  From Simon Gillbee