LINUX.ORG.RU

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

 ,


1

1

Уточняю: понятно что некоторые поля классов и т.д. должны быть закрыты от доступа извне. Однако что дает сеттер и геттер вся работа которых, просто тупо присвоить значение без каких-либо проверок или же отдать значение без проверок. В чем сакральное преимущество перед обычным присвоением или прямым доступом к полю у такого сеттера\геттера? Когда внутри сеттера есть проверки на корректность входного значения, то зачем он-- понятно

★★★★★

Последнее исправление: pylin (всего исправлений: 2)

вся работа, которых просто тупо присвоить значение без каких-либо проверок

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

kelyar ★★★★★
()

А если серьёзно, то можно поменять логику с простого присвоения на что-то более сложное, не меняя api.

PolarFox ★★★★★
()

Обычно в промышленном коде преимущественно присутствуют геттеры и сеттеры в снутренними проверками или другой обработкой данных. Если и встречаются прямые, без дополнительного функционала, то только потому, что нерадивый девелопер забыл заимплементить проверку, либо она банально не нужна, но для единообразности кода сделали передачу данных через get/set

IvS
()

Унификация интерфейса доступа к объекту: все через методы. При необходимости геттеры-сеттеры могут быть усложнены без модификации использующего их кода, в т.ч. упрощается отладка.

Сам ограничегго использую геттеры, очень ограниченно сеттеры и почти никогда не работаю с полями структур напрямую.

staseg ★★★★★
()
Ответ на: комментарий от PolarFox

Оба варианта понятны и здравы, спасибо. у то есть я правильно понял что сеттер и геттер как раз таки нужно нагружать проверочной логикой, во всяком случае никакого извращения в этом нет.

pylin ★★★★★
() автор топика

Завтра у тебя значение будет доставаться не из поля, а из базы или из интернета. Если у тебя был доступ к полю, придется переделывать все для ввода новых методов. А если уже были методы, нужно будет только поменять их внутренности.

vurdalak ★★★★★
()

Предположим, что сначала проверки были не нужны, и мы напрямую обращались к полю f, но потом проверки понадобились. Тогда придется во всей кодовой базе менять все присваивания вида obj.f = ... на obj.setF(...). А если бы мы использовали сеттеры изначально, то достаточно было бы поменять только сам код сеттера, что гораздо проще. Таким образом, пустые методы доступа — это страховка на случай будущих изменений.

CARS ★★★★
()
Последнее исправление: CARS (всего исправлений: 1)

<slowpoke>Вы знаете, Бритни Спирс налысо побрилась</slowpoke>

Это уже сто раз обсудили и все, кроме самых упоротых, согласны что это было плохое инженерное решение сокрытия полей класса.

Они призваны решать проблему пролезания полей в публичный доступ, когда в будущем прийдется добавать кое-какой код валидации в сеттер или вычисления в геттер, а пользователи класса уже наворотили код, который бинарно совместим только с полем.

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

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

Всем спасибо, как я и понимал изначально: а) эта пара нужна для того, чтобы, например проконтролировать внешние данные или отформатировать их для вывода на запрашивающую сторону б) Предоставить единый интерфейс для работы с данными. Эта мысль была, но как-то нечетко сформулированной в голове

pylin ★★★★★
() автор топика

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

anonymous
()
Ответ на: комментарий от anonymous

Ну вот, а тут легаси конечно. Хотя думаю фича не сложная для запила в будущих версиях. Ориентировочно понятно как оно должно быть реализовано с учетом обратной совместимости

vertexua ★★★★★
()
Ответ на: комментарий от vurdalak

А реально в работе такое случалось? У меня есть подозрение, что это одно из глупых предположений, которое делают многие программисты, типа «а что если», и давай высосем из пальца эти варианты. Представь я в хотлупе вынимал эти значения, а ты теперь туда сетевой запрос воткнул. Очевидно вынимать надо теперь булком, а не по одной штучке за раундтрип. Интересно посмотреть на пример, когда старые ожидания прозрачно оправдываются.

arturpub ★★
()
Ответ на: комментарий от arturpub

Зависит от размеров проекта. Если это что-то одноразовое, то может и не случиться того самого «если». А если у тебя проект на 10 лет, недальновидных разработчиков будут крыть последними словами, когда придется что-то менять.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

Но ведь конкретно этот случай (геттер вс прямой доступ) не так сложно поймать — компилятор все равно увидит все места и заставит исправить. Другое дело внешние зависимости, например ты библиотека, которую юзают другие проекты, но такая совместимость наверное отдельная песня не на самотеке. В общем по мне так все равно профиты наверное мнимые, это больше «корпоративные стандарты», чем полезная практика.

arturpub ★★
()
Ответ на: комментарий от arturpub

Мнимые? Вот тебе еще пример - жил был был параметр с прямым доступом, потом бац, он стал вычисляемым и/или lazy (а такое часто встречается). Твои действия? Делать геттер? Но получается, что часть параметров с прямым доступом, часть через геттеры. Красиво и юзабельно? Нет. Посему проще заранее соломку подстелить, делать геттеры и сеттеры.

zJes ★★
()
Ответ на: комментарий от arturpub

компилятор все равно увидит все места и заставит исправить

Да, только исправление займет не один день, учитывая тесты. Когда можно было добавить 2 метода сразу за 5 минут.

В общем по мне так все равно профиты наверное мнимые

Наверное это бесполезно обсуждать. Пока IRL не встретишь, профит не будет очевиден.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

Да, только исправление займет не один день, учитывая тесты.

Может надо нормальные инструменты использовать, которые автоматизируют подобные банальные действия?

Когда можно было добавить 2 метода сразу за 5 минут.

И потом удивляться, почему всё так нещадно тормозит, если классов 100500 штук, и у каждого из 100500 полей каждого из 100500 объектов вся работа идёт через методы, а и вдруг ещё через виртуальные...

yyk ★★★★★
()
Ответ на: комментарий от yyk

Может надо нормальные инструменты использовать, которые автоматизируют подобные банальные действия?

libastral-cli?

И потом удивляться, почему всё так нещадно тормозит, если классов 100500 штук, и у каждого из 100500 полей каждого из 100500 объектов вся работа идёт через методы, а и вдруг ещё через виртуальные...

А надо все в однострочнике и с прямым доступом? Ну что ж, можно и так. Только это будет продукт на 1 раз, для любого изменения нужно будет переписывать с нуля.

vurdalak ★★★★★
()
Ответ на: комментарий от zJes

Ты же не знаешь в общем виде, где стелить, а где нет. Если ооп подразумевает такое в качестве бест-практисес, то почему в некоторых ооп-языках, в т.ч. и сабжевом, нет прозрачности филд-vs-проперти? Почему в синтаксис не включают оператор "." или инплейс перегрузку поля геттером и сеттером?

arturpub ★★
()
Ответ на: комментарий от CARS

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

vertexua ★★★★★
()
Ответ на: комментарий от yyk

Оптимизатор стирает тривиальные геттеры и сеттеры

vertexua ★★★★★
()
Ответ на: комментарий от arturpub

Почему не знаю? Некоторый опыт то есть, обычно при разработке знаешь/предполагаешь/попой чуешь где могут быть проблемы. И кстати, какой сабжевый язык? :)

К примеру, в d, python есть клевые декораторы @property, в которые можно заворачивать методы. То есть тут, с точки зрения использования, всегда прямой доступ. Вот такой синтаксический сахар мне нравится.

И кстати, ооп тут как бы и не при делах.

zJes ★★
()

А кому-нибудь хоть раз приходилось менять тривиальные геттеры-сеттеры на нетривиальные? У меня вот есть такое ощущение что подобной ситуации не было никогда ни разу ни в одном проекте.

Absurd ★★★
()

1. Защита от дурака

2. Возможность в будущем добавить что-то более интеллектуальное чем this.isActive = isActive

crowbar
()
Ответ на: комментарий от pylin

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

можно (не обязательно нужно).

во всяком случае никакого извращения в этом нет.

это нормально (когда нужно).

dzidzitop ★★
()
Ответ на: комментарий от arturpub

А реально в работе такое случалось?

Случалось. В том числе было и наследование с переопределением set/get чтобы не поломать API (это было вынужденной мерой).

dzidzitop ★★
()
Ответ на: комментарий от yyk

Может надо нормальные инструменты использовать, которые автоматизируют подобные банальные действия?

этот инструмент называется setX()/getX().

dzidzitop ★★
()
Ответ на: комментарий от yyk

И потом удивляться, почему всё так нещадно тормозит, если классов 100500 штук, и у каждого из 100500 полей каждого из 100500 объектов вся работа идёт через методы, а и вдруг ещё через виртуальные...

Примитивные (и не только set/get) инлайнятся почти всегда.

dzidzitop ★★
()
Ответ на: комментарий от vertexua

так вот он какой - язык программирования, который всё делает за программиста.

dzidzitop ★★
()
Ответ на: комментарий от pylin

А что понимается подбесплатные?

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

Но при этом они позволяют захватывать переменные из контекста где они об'являются.

Не вижу причины ими не пользоваться.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

а в _хороших_ такого нет.

Хороших языков вообще нет. Есть нормальные, есьт говняные.

anonymous
()
Ответ на: комментарий от dzidzitop

этот инструмент называется setX()/getX().

Это не инструмент - это куча ненужного бойлерплейта.

anonymous
()
Ответ на: комментарий от dzidzitop

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

Но при этом они позволяют захватывать переменные из контекста где они об'являются.

Так не бывает.

anonymous
()

Чаще всего они нарушают инкапсуляцию. Заключается это в том, что вместо продумывания адекватного интерфейса класса разработчик генерит в еклипсе аксессоры для всех полей и получает структурный код, замаскированный под ололо-Ъ-ынтырпрайз-ООП. Подробнее здесь

Laz ★★★★★
()

Возможность изменять реализацию класса без перекомпиляции (в случае жавы без переписывания) тех, кто им пользуется.

Legioner ★★★★★
()
Ответ на: комментарий от vurdalak

Завтра у тебя значение будет доставаться не из поля, а из базы или из интернета.

А послезавтра надо будет переписывать вообще весь код, потому что item.getPrice() теперь работает в 100 раз дольше, а employee.getName() вообще может выкинуть host not found.

Laz ★★★★★
()

Обобщаем, сеттер и геттер вводят промежуточный слой обработки, где может происходить:
* унификация процедур доступа независимо от вида источников данных
* авторизция действий (вообще, есть привилегия это cделать этому пользователю, в таком контексте, и т.д.?)
* валидация по доступности источника данных для указанного действия (например, БД, WEB-сервис, вызов локальной проги, структура в памяти, работоспособность, актуальность, консистентность состояния, блокировано кем-то, установлена блокировка мной, и т.д.) и обработка исключений
* установка/выборка значений в/из структур, где они хранятся, и локализация нужных данных (например, понадобилось контролировать несколько байт в блоке данных)
* валидация значений по типу и формату хранения данных в контексте источника данных
* валидация значений по типу и формату представления данных в нашем контексте
* валидация по логике (например, 0 < VALUE < 100 ,для процентов)
* ну и т.д. и т.п.

anonymous
()
Ответ на: комментарий от Laz

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

arturpub ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.