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


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.