ООП ГМ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так оно и есть в нормальных языках.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

libastral-cli?

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

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

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

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

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

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

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

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

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

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

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

use Ruby

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

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

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

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

synchronized/override/whatever-else ты потом куда совать будешь?

Так оно и есть в нормальных языках.

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

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

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

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

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

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

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

man scala

эталонный джавист. Лямбды не нужны?

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

Бесплатные плюсовые лямбды юзаю с удовольствием. До Java 8 доберусь не скоро.

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

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

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

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

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

ясно, спасибо

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

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

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

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

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

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

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

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

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

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

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

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

Стабильный ABI

asm listings не согласны.

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