Зачем использовать бессмысленные сеттеры/геттеры?

Question

[Вова]

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

Однако, иногда я замечаю вот такое:

class BlaBlaBla {
public:
  URLID id() const { return id_; }
  void set_id(URLID id) { id_ = id; }
...

И никак не могу понять, зачем это? На мой вкус это что-то сродни Overengineering-а и не несёт никакого смысла.

Или я ошибаюсь?

Answer 1

[Толстый Лорри]

Когда вам потребуется добавить в сеттер валидацию, а в геттер - кэширование, то не придется менять вызовы в клиентском коде. К тому же, аксессоры можно делать виртуальными.

IDE прекрасно генерирует такой код, равно как и он сам легко оборачивается в макрос. Многие компиляторы так же имеют языковые расширения, позволяющие реализовать properties в C++.

Answer 2

[Илья Герасимов]

Значение может быть, например, приватным. И мы хотим быть уверены что там всегда именно то, что мы ожидаем, геттеры и сеттеры, как и многий сахар, просто предотвращают ошибки/невнимательность программиста

Comments

[Вова]

Может. И скорее всего так и есть.
Но геттер и сеттер публичны. Поэтому доступ всё равно есть у всех.
И кажется, что можно было просто выкинуть методы, а член id_ поместить в public.
Результат был бы тем же.

В общем, не понимаю.

[Илья Герасимов]

Вова, суть в сеттере, само значение как правило protected или private, сеттером чекаем что пришло, считаем на основе чего-то еще, запоминаем, делаем что-то еще, геттером отдаем. И чтобы постоянно не повторять логику сеттера это выводится в метод. В основном это упрощает жизнь, но бывает пишется как кажется "лишний" код. Сейчас вообще много где пишется куча казалось бы лишнего кода, на практике в дальнейшем помогает, когда это все разносится в кучу кода, который даже если сам писал, начинаешь сложно понимать.

[JaxxDexx]

Вова, сегодня вам нужно просто установить новое значение переменной, а завтра понадобится добавить проверку перед установкой переменной... А этих установок куча по всей программе, будете везде проверку лепить? Намного удобнее сделать интерфейс взаимодействия, а потом в других частях кода тупо его использовать.

[Вова]

Ну, то есть единственная разумная причина - этакий задел на будущее. Да?
(Вообще, у меня даже в несвежем FAR есть find/replace. Хмхм).

Answer 3

[Дмитрий]

Причин может быть достаточно много.
1. Что если сегодня поле расположено в виде закрытой переменной, а завтра будет доставаться из HTTP-ответа ?
2. Что если сегодня оно в виде хранимого значения, а завтра станет вычисляемым?
3. Что если сегодня оно в этом классе, а завтра решили перенести в другой, а чтобы не делать слишком большой рефакторинг пока решили оставить как есть?
4. Что если сегодня это свойство этого класса, а завтра родительского?

Причин множество! Геттеры и сеттеры спасают от головных болей.