Я подключился к проекту и увидел, что другие разработчики добавляют много логики в установщики синтезированных свойств. Я понимаю, как это работает, но я думаю, что это затрудняет понимание хода программы; читая код, всякий раз, когда я вижу self.something = whatever, я всегда проверяю, somethingпереопределен ли setter.
Что вы думаете об этой теме? Как вы думаете, это признак плохой архитектуры или сложного решения?
Я был бы рад прочитать больше об этом, если у вас есть соответствующие ссылки / источники, просто слишком сложно получить хорошие результаты Google, поэтому я решил спросить здесь.
Спасибо за любой ответ и, пожалуйста, обратите внимание, что я говорю о цели C на тот случай, если вы не видели тег (хотя это не должно быть языковой проблемой).
Ответы:
нет
Свойства были изобретены, чтобы позволить дизайнерам классов иметь логику, привязанную к удобному интерфейсу доступа к полю и назначения.
Сколько это слишком много? Это зависит от обязанностей класса. Вот некоторые вещи, которые целесообразно добавить в установщик свойств:
Программирование легче, когда у классов есть интерфейсы, которые делают очевидным, что класс может делать, не заставляя вызывающих думать о том, как это делается. Размещение логики за установщиками свойств позволяет классам скрывать свою реализацию за простым интерфейсом. Для некоторых классов методы не требуются. Просто поверните ручки, установив свойства, и прочитайте вывод, получив свойства.
источник
Сеттеры обычно используются для изменения состояния объекта без каких-либо значительных побочных эффектов или сложных вычислений, для этого используйте методы и функции. Основной причиной реализации сеттера является изменение и поддержание действительного состояния . Таким образом, ограничение диапазона, установка флагов для запроса на перерасчет или настройка связанных свойств абсолютно приемлемы.
источник
Я не знаю о цели C, но, как вы говорите, это кажется достаточно общим вопросом для любого языка OO. Прежде всего и на самом деле связано с этим, вопрос о том, иметь ли сеттеры и геттеры в первую очередь, является предметом обсуждения (в некоторых случаях их существование оправдывается использованием фреймворка или библиотеки).
Я считаю, что название метода должно объяснять, что метод делает, и весь метод делает. Кроме того, документация, связанная с этим методом, должна описывать его более явно. В этом смысле имя метода в форме «set» + {имя существительное} не должно иметь никаких побочных эффектов, кроме установки значения переменной, и это должно быть единственным действием, связанным с ним. Проверка того, что аргумент действителен, является приемлемым, но это должно быть описано в его документации.
источник