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

Question

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

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

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

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

Answer 1

" Однако конструктор VS, похоже, не реализует такие методы получения / установки для тех общедоступных объектов, которые являются компонентами формы (и, следовательно, не соответствуют хорошей практике программирования). * Если вы имеете в виду элементы управления, которые вы перетаскиваете на форму, они помечаются как частные элементы экземпляра и добавляются в коллекцию элементов управления формы. Почему они были бы иначе? Форма может иметь сорок или пятьдесят элементов управления, было бы несколько ненужным и громоздким, чтобы обеспечить получение / установщик для каждого элемента управления в форме. Дизайнер оставляет за вами право предоставлять делегированный доступ к определенным элементам управления через общедоступные методы получения / установки.

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

Answer 2

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

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

У зрелого решения, вероятно, будут следующие пункты проектирования:

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

И это даже не относится к таким вещам мета-разработки, как юнит-тесты.

Answer 3

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

Answer 4

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

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