如果我有一個組件/對象，如我需要從父母或其他窗體訪問的組件/對象，我顯然需要將修改器升級到此組件到內部或公共級變量。我應該爲表單上的公共/受保護組件提供訪問方法/ Getter Setter嗎？
現在，如果我在表單類中提供了一個int或字符串類型的公共變量，我不會考慮在這個方面使用Getters和（也許）Setter，即使他們沒有做任何事情除了提供對變量的直接訪問。
但是，VS設計人員似乎沒有爲表單上組件的公共對象實現這樣的Getters/Setters（因此不符合良好的編程習慣）。
所以，問題是，爲了做到「正確的事情」，我應該將這樣的VS設計器組件還是對象包裝在Getter和/或Setter中？
「然而，VS設計師似乎並沒有實現這樣的getter/setter方法對於那些在窗體上的組件（因此不符合良好的編程習慣）。公共對象」
如果您指的是您拖放到表單上的控件，這些控件被標記爲私有實例成員並被添加到表單的Controls集合中。他們爲什麼會這樣呢？一個表單可能有四十個或五十個控件，爲表單上的每個控件提供一個getter/setter會有點不必要和笨拙。設計師將它留給你，通過公共的getter/setter提供對特定控件的委託訪問。
設計師在這裏做正確的事情。
我總是這樣做，如果你遵循MVP設計，爲你的視圖組件創建getter/setters將是一個設計需求。
我不明白你的意思是「不符合良好的編程習慣」。微軟違反很多良好的編程實踐，使它更容易在Visual Studio上創建的東西（爲了快速的應用程序開發），我沒有看到缺乏控制的getters/setters作爲違反任何這種最佳實踐的證據。
對錶單上的組件執行Getters和Setter的原因我相信是因爲它們不會是「線程安全的」.Net對象只能被創建它們的表單線程修改，如果你把對於吸氣劑和吸附劑，你可能會打開它的任何線程。相反，您應該實現一個委託系統，將對這些對象的更改委託給創建它們並在那裏運行的線程。
這是封裝在面向對象設計中的一個典型例子。
表單是一個對象，其職責是向用戶呈現UI並接受輸入。 Form對象和代碼的其他區域之間的接口應該是面向數據的接口，而不是暴露Form的內部實現細節的接口。表單（即控件）的內部工作應該隱藏在任何消費代碼中。
成熟的解決方案可能會涉及以下設計要點：
而這甚至沒有提到單元測試這樣的元開發事物。