Геттер и сеттер: что они дают?

Не согласны с объективной реальностью? Ну покажи мне как инлайнится лямбда, переданная параметром в рекурсивную функцию. В map, например.

Каждый придумал парочку аргументов в пользу геттеров и сеттеров, по факту, модно и молодежно падать в крайности. Это всего лишь инструмент и применяться должен к месту, а не потому-что в книжке написано делай так.

Что за map я хз. А в своей одной программе имею соотношение инлайнутые лямбды/неинлайнутые где-то 9/1.

дополнительный слой абстракции создающий «не ломающийся» API.

например:

v0 имеем только одно частное поле

Class {
  private string address

  void|boolean setAddress(string address)
  string getAddress(void)
}

v1 добавляем порт, в set распарсиваем, в get собираем uri

Class {
  private string address
  private int port

  void|boolean setAddress(string uri)
  string getAddress(void)
}

v2 добавляем протокол, в set распарсиваем, в get собираем uri

Class {
  private string address
  private int port
  private enum protocol

  void|boolean setAddress(string uri)
  string getAddress(void)
}

в итоге снаружи класса ничего не изменилось и все что было написано для первого варианта не придется переделывать

писать код нужно учиться.

И на что ты их поменяешь, стесняюсь спросить?

На getPricesForItems(items) и bool getName(&name), очевидно.

без каких-либо проверок или же отдать значение без проверок

А если потом проверка понадобится? Добавлять ее в 100500 местах где ты эту переменную присваивал?

Сферический пример? Понадобилось на один параметр добавить кучу проверок - сделал сеттер и сделал установку значения через сеттер. В чем проблема?

прамблема в том что есть public API которое юзают клиенты код которых ты не перепишешь.

С этим согласен, интерфейс предоставляемый наружу в другие модули или сошки должен быть универсальным. Если смотреть на классы внутри одного проекта - большого смысла не вижу везде делать геттеры и сеттеры.

с private API отдельный разговор.

Понадобилось на один параметр добавить кучу проверок - сделал сеттер и сделал установку значения через сеттер. В чем проблема?

В том что эта переменная уже изменяется в сотне мест? И везде надо менять присваивание на сеттер.

Не вижу проблемы, а то что вы пишете тысячи никогда не пригодившихся сеттеров и геттеров это нормально, где логика?

а то что вы пишете тысячи никогда не пригодившихся сеттеров и геттеров это нормально, где логика?

очень удобно ставіть туда брейкпойнты + возможно добавлять logging

Вы падаете в крайности, инструмент должен применяться к месту, если не к месту ради каких либо выдуманных причин - выглядит просто глупо.

Я брейкпойнты ставлю в set/get достаточно часто (в чужом коде).

А так - инкапсуляции достаточно чтобы писать set/get. Остальное - бонусы.

Проблема нагороженных геттеров и сеттеров идет от факта, что объекты мутабельны. Поля объекта устанавливаются и меняются из тысяче мест, в результате чего часто необходима валидация и там и тут и ненужные обертки. Вопрос, а как вы красиво реализовываете валидацию в сеттерах? Вешаете на определенные сеттеры и кидаете иксепшн?

Длиннее хелло ворда что-нибудь писалось? Особенно евент дривен или ассинхронное? Поговаривают, что очень быстро приучает писать геттеры и сеттеры везде, ну может быть кроме приватных структур. :)

Вопрос, а как вы красиво реализовываете валидацию в сеттерах?

if (!cond) throw SomeException;

Естественно писалось, а судя по вашей записи «поговаривают» - сами вы это на опыте не поняли, лишь потому что «умный» дядя сказал так делать - делаете

сеттер и геттер как раз таки нужно нагружать проверочной логикой

насчет геттера не уверен.

(Это был мой комментарий к Геттер и сеттер: что они дают? (комментарий))

ну с геттером я и сам не уверен, там наверно ничего делать не надо кроме подготовки данных к отдаче)

Более хорошим решением было бы если-бы компилятор генерировал геттеры и сеттеры и подставлял их везде тоже сам. А потом все это стиралось оптимизатором уже при запуске. В такой модели всегда потом можно написать сеттер и геттер явно

Именно так и сделаны property в Object Pascal. property X read PrivateVarX на раз превращается в property X read GetX.

«поговаривают» это был словесный оборот, для придания небольшой доли сарказма. :)
Да я и не против слушать умных дядей, чай не буратин.

например synchronized / std::mutex::lock()