Должен ли я предоставлять методы доступа / настройки получения для общедоступных / защищенных компонентов в форме?

Question

Если у меня есть .Net Form с компонентом / объектом, таким как текстовое поле, к которому мне нужно получить доступ из родительской или другой формы, мне, очевидно, нужно "обновить" модификатор этого компонента до внутренней или общедоступной переменной уровня.

Теперь, если бы я предоставлял общедоступную переменную типа int или string и т.д.в моем классе form я бы не стал дважды думать об использовании геттеров и (возможно) сеттеров для этого, даже если бы они не делали ничего, кроме предоставления прямого доступа к переменной.

Однако VS designer, похоже, не реализует такие методы получения / установки для тех общедоступных объектов, которые являются компонентами формы (и, следовательно, не соответствуют надлежащей практике программирования).

Итак, вопрос в том,;Чтобы сделать "правильную вещь", должен ли я обернуть такие компоненты или объекты VS designer в Getter и / или Setter?

Answer 1

"Однако VS designer, похоже, не реализует такие методы получения / установки для тех общедоступных объектов, которые являются компонентами формы (и, следовательно, не соответствуют надлежащей практике программирования)."

Если вы имеете в виду элементы управления, которые вы перетаскиваете в форму, они помечаются как элементы частного экземпляра и добавляются в коллекцию элементов управления формы.Почему они должны быть другими?Форма может содержать сорок или пятьдесят элементов управления, было бы несколько ненужным и громоздким предоставлять средство получения / установки для каждого элемента управления в форме.Разработчик оставляет за вами право предоставлять делегированный доступ к определенным элементам управления через общедоступные средства получения / установки.

Дизайнер здесь поступает правильно.

Answer 2

Причина, по которой я не внедряю геттеры и установщики для компонентов в форме, я полагаю, заключается в том, что они не были бы "потокобезопасными". Предполагается, что объекты .Net изменяются только потоком формы, который их создал, если вы используете getter и setters, вы потенциально открываете его для любого потока.Вместо этого вы предполагаете реализовать систему делегирования, в которой изменения в этих объектах делегируются потоку, который их создал и запустил там.

Answer 3

Это классический пример инкапсуляции в объектно-ориентированном проектировании.

Форма - это объект, в обязанности которого входит представление пользовательского интерфейса пользователю и прием входных данных.Интерфейс между объектом Form и другими областями кода должен быть ориентированным на данные интерфейсом, а не интерфейсом, который предоставляет информацию о внутренней реализации Формы.Внутренняя работа Формы (т. Е. элементы управления) должна оставаться скрытой от любого используемого кода.

Зрелое решение, вероятно, включало бы в себя следующие моменты проектирования:

• Общедоступные методы или свойства являются поведенческими (показывать, скрывать, позиционировать) или ориентированными на данные (устанавливать данные, получать данные, обновлять данные).
• Все обработчики событий, реализованные Формой, обернуты в соответствующий код делегирования потоков для обеспечения соблюдения правил выполнения потоков Формы.
• Сами элементы управления будут привязаны к базовой структуре данных (где это уместно) для сокращения объема кода.

И это даже не говоря о таких вещах метаразработки, как модульные тесты.

Answer 4

Я всегда так делаю, и если вы следуете дизайну MVP, создание геттеров / установщиков для ваших компонентов представления было бы требованием к дизайну.

Я не понимаю, что вы подразумеваете под "не соответствует надлежащей практике программирования".Корпорация Майкрософт нарушает очень много из хороших практик программирования, облегчающих создание материалов в Visual Studio (ради быстрой разработки приложений), и я не рассматриваю отсутствие геттеров / установщиков для элементов управления как свидетельство нарушения каких-либо таких лучших практик.