Считается ли плохой практикой добавлять логику в установщик свойств?


28

Я подключился к проекту и увидел, что другие разработчики добавляют много логики в установщики синтезированных свойств. Я понимаю, как это работает, но я думаю, что это затрудняет понимание хода программы; читая код, всякий раз, когда я вижу self.something = whatever, я всегда проверяю, somethingпереопределен ли setter.

Что вы думаете об этой теме? Как вы думаете, это признак плохой архитектуры или сложного решения?

Я был бы рад прочитать больше об этом, если у вас есть соответствующие ссылки / источники, просто слишком сложно получить хорошие результаты Google, поэтому я решил спросить здесь.

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


5
Что за логика? Например, нет ничего плохого в том, чтобы поставить логику проверки. С другой стороны, установщик, который отправляет несколько событий, вызывает веб-сервис и обновляет пользовательский интерфейс, совершенно неверен.
Арсений Мурзенко

@MainMa Я согласен, что проверки в порядке - может быть, добавление некоторых наблюдателей, не так ли? Не могли бы вы привести несколько примеров того, что вы считаете более подходящим для установки?
фи

действительно, наблюдатели правы. Что касается вещей, которые подходят для сеттера, я позволю более опытным разработчикам ответить на этот вопрос.
Арсений Мурзенко

Ответы:


44

Считается ли плохой практикой добавлять логику в установщик свойств?

нет

Свойства были изобретены, чтобы позволить дизайнерам классов иметь логику, привязанную к удобному интерфейсу доступа к полю и назначения.

Сколько это слишком много? Это зависит от обязанностей класса. Вот некоторые вещи, которые целесообразно добавить в установщик свойств:

  • обновить некоторые производные значения
  • уведомить наблюдателей о том, что классовое состояние изменилось
  • распространять изменения на некоторые содержащиеся объекты
  • распространять изменения в бэк-магазине
  • выполнить проверку

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


13
Выполните проверку ...
Роберт Харви

Насколько хорошо перезагрузить коллекционное представление или табличное представление в переопределенном методе сеттера?
Кришнан

15

Сеттеры обычно используются для изменения состояния объекта без каких-либо значительных побочных эффектов или сложных вычислений, для этого используйте методы и функции. Основной причиной реализации сеттера является изменение и поддержание действительного состояния . Таким образом, ограничение диапазона, установка флагов для запроса на перерасчет или настройка связанных свойств абсолютно приемлемы.


7

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

Я считаю, что название метода должно объяснять, что метод делает, и весь метод делает. Кроме того, документация, связанная с этим методом, должна описывать его более явно. В этом смысле имя метода в форме «set» + {имя существительное} не должно иметь никаких побочных эффектов, кроме установки значения переменной, и это должно быть единственным действием, связанным с ним. Проверка того, что аргумент действителен, является приемлемым, но это должно быть описано в его документации.


1
+1 за "есть ли сеттеры и геттеры". И еще +1 для «имени метода должно объяснить, что он делает».
Авв
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.