Идеологически правильный setter? Представим себе ситуацию — есть некоторый класс, например Subscriber, у которого есть приватное поле string Subscriber::email и метод, устанавливающий его значение Subscriber::setEmail(string val).
Очевидно, что можно попытаться задать через этот сеттер некорректный адрес (например, не содержащий символ @).
Вопрос: 1. Должен ли этот сеттер проверять корректность мыла?
2. Если должен, то каким образом он должен сигнализировать о некорректном вводе?
Через возвращаемое значение или через исключение?
P.S. Прошу принять во внимание следующие доводы:
+каждый метод должен быть ответственен за одно действие, а в п.1 мы пытаемся возложить на этот сеттер и проверку значения и установку поля.
+если все же примериться с этим, и заставить метод возвращать false при попытке ввода некорректного мыла, то тогда придется каждый раз писать if (!s->setEmail(«blah-blah»)) {...} — как-то это слишком, мне кажется.
+исключение нужно генерировать тогда, когда ошибку нельзя исправить в том месте, где она была обнаружена. Обычно так бывает при большой вложенности стека вызовов функций, а в нашем случае исключение кажется не совсем уместным.
Идеологически правильный setter? Представим себе ситуацию — есть некоторый класс, например Subscriber, у которого есть приватное поле string Subscriber::email и метод, устанавливающий его значение Subscriber::setEmail(string val).
Очевидно, что можно попытаться задать через этот сеттер некорректный адрес (например, не содержащий символ @).
Вопрос: 1. Должен ли этот сеттер проверять корректность мыла?
2. Если должен, то каким образом он должен сигнализировать о некорректном вводе?
Через возвращаемое значение или через исключение?
P.S. Прошу принять во внимание следующие доводы:
+каждый метод должен быть ответственен за одно действие, а в п.1 мы пытаемся возложить на этот сеттер и проверку значения и установку поля.
+если все же примериться с этим, и заставить метод возвращать false при попытке ввода некорректного мыла, то тогда придется каждый раз писать if (!s->setEmail(«blah-blah»)) {...} — как-то это слишком, мне кажется.
+исключение нужно генерировать тогда, когда ошибку нельзя исправить в том месте, где она была обнаружена. Обычно так бывает при большой вложенности стека вызовов функций, а в нашем случае исключение кажется не совсем уместным.
Очевидно, что можно попытаться задать через этот сеттер некорректный адрес (например, не содержащий символ @).
Вопрос: 1. Должен ли этот сеттер проверять корректность мыла?
2. Если должен, то каким образом он должен сигнализировать о некорректном вводе?
Через возвращаемое значение или через исключение?
P.S. Прошу принять во внимание следующие доводы:
+каждый метод должен быть ответственен за одно действие, а в п.1 мы пытаемся возложить на этот сеттер и проверку значения и установку поля.
+если все же примериться с этим, и заставить метод возвращать false при попытке ввода некорректного мыла, то тогда придется каждый раз писать if (!s->setEmail(«blah-blah»)) {...} — как-то это слишком, мне кажется.
+исключение нужно генерировать тогда, когда ошибку нельзя исправить в том месте, где она была обнаружена. Обычно так бывает при большой вложенности стека вызовов функций, а в нашем случае исключение кажется не совсем уместным.
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Ответ на данный вопрос может зависеть от общих принципов дизайна и стиля кодирования в конкретном проекте или команде. Однако, в целом, в идеологически правильном подходе setterы не должны выполнять дополнительные проверки и логику, кроме самой установки значения.
Проверка корректности данных обычно выполняется в других частях кода, например, в момент передачи данных в setter или в методе, который использует это значение. Поэтому, если необходимо проверить корректность мыла, это следует сделать в другом месте, а setter должен просто устанавливать переданное значение.
Если все же решено включить проверку в setter, то для сигнализации о некорректном вводе может использоваться возвращаемое значение либо исключение. Использование возвращаемого значения позволит легче обрабатывать ошибки в коде вызывающей стороны, но при этом может привести к возможности игнорирования результата проверки. Использование исключения сделает код более чистым, так как ошибку можно будет обрабатывать в более позднем контексте, но может усложнить логику вызывающего кода.
Наконец, важно помнить о принципе единственной ответственности, поэтому если проверка корректности данных предполагается выполнять в setter, то лучше применить подход с возвращаемым значением и предоставить более высокоуровневым частям кода решать, что делать в случае некорректного значения.