Зачем нужны "set" и "get" в классах

Зачем нужны "set'еры" и "get'еры", если к public членам можно обращаться через указатель на класс. Видел ответы типо: "Так принято", но ведь при обращении к члену класса напрямую быстродействие увеличивается, чем при вызове целой функции. Вообще хочу чётких доказательств "ЗА" и "ПРОТИВ".

0

При обращении через ссылку:
практически также, как напрямую.
А зачем это нужно? Ну, например, set методы позволяют контролировать устанавливаемые значения, допустим, у нас есть класс Player и мы хотим установить громкость для плеера, тогда разумно сделать метод void setVolume(int value); который будет проверять, что аргумент находится в пределах [0, 100] и если это не так либо генерить исключение, либо округлять до ближайшей границы. Ну и конечно "так принято", если в какой-то библиотеке часть переменных класса будут устанавливаться через get/set, а часть напрямую, пользоваться ей будет не удобно.

Добавлено через 2 минуты
Но использовать их везде, как в мире джавы, тоже мне кажется не лучшей идеей, для совсем тривиальных вещей, которые просто хранят данные, имхо, можно обойтись без геттеров и сеттеров

0

buridan, Довод "ЗА" один и простой - это инкапсуляция, один из "столпов" ООП вообще.

Сообщение от buridan но ведь при обращении к члену класса напрямую быстродействие увеличивается

Быстро и хорошо - не одно и то же (если не верите - спросите у своей девушки ) Огромная часть ошибок - ошибки входных данных. Поместить проверку на корректность в сеттер или в 100500 мест кода - что лучше? Геттер нужен для того же (чтоб шаловливыми ручками не изменяли данные внутри класса по ссылке).
Можно и без них, просто это другой подход и, в частности, там где нужна скорость используют C с POD структурами и не парятся.

6

buridan,
В дополнение к вышесказанному почитайте ещё про инкапсуляцию

0

Сообщение от avgoor Быстро и хорошо - не одно и то же (если не верите - спросите у своей девушки )

а если её нет?

0

Сообщение от buridan Зачем нужны "set'еры" и "get'еры", если к public членам можно обращаться

Это называется "инкапсуляция" и/или "разделение интерфейса и реализации".

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

Наличие set/get ничего подобного не констатирует. За set/get может не стоять никакого поля вообще. А может и стоять, но располагаться совсем в другом месте, а не в этом классе. И через set/get с полем (даже если оно существует) не получится делать что угодно, а получится делать только set/get.

Это - гигантская разница, ради которой и делается доступ через set/get.

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

0

Сообщение от buridan но ведь при обращении к члену класса напрямую быстродействие увеличивается

Большинство компиляторов оптимизируют все ваши get/set'ы таким образом как они бы выглядели при прямом доступе к полям.

1

Сообщение от buridan Зачем нужны "set'еры" и "get'еры", если к public членам можно обращаться через указатель на класс.

Избегая setter/getters, ты привязываешь клиентов класса к его внутреннему устройству.
Если класс будет использоваться в 100500 местах, то поменять его интерфейс потом
будет очень трудно. Представь, что когда-нибудь тебе потребуется перед записью или
чтением данного поля захватывать какую-нибудь блокировку или изменять счетчик ссылок.
Без setter/getter это превратится в объемный рефакторинг и неизбежные опечатки, ошибки...
А если setter/getter уже есть, правки займут несколько минут.

0

Сообщение от Someone007 Большинство компиляторов оптимизируют все ваши get/set'ы таким образом как они бы выглядели при прямом доступе к полям.

А как проверить была ли оптимизация или нет?

Думаю если мы пишем вызов метода нужно быть готовым платить за это

0

Раз уж сказали все "ЗА", расскажу про ситуацию "Против".
Если вся реализация класса состоит лишь из скрытых(private/protected) свойств и набора get-set методов для них, при этом нам не нужно (и с высокой вероятностью никогда не будет нужно) дополнительно что-то делать при изменении/обращении к свойству, то смысла в таком классе нет. Гораздо прозрачнее назвать его структурой и обращаться к полям напрямую. Хотя это моё личное мнение и нигде не стандартизировано.

Добавлено через 1 минуту

Сообщение от sys_beginner А как проверить была ли оптимизация или нет?

АСМ.

Да и методы из одной тривиальной инструкции с присваиванием почти наверняка будут встроены. Тут и inline не пиши к бабке не ходи.

1

Сообщение от MrGluck при этом нам не нужно (и с высокой вероятностью никогда не будет нужно) дополнительно что-то делать при изменении/обращении к свойству

Заранее же неизвестно
А если приспичит то платить придется дорого

Добавлено через 1 минуту

Сообщение от MrGluck АСМ.

Жесть. Это весь код нужно в АСМ читать, причем для всех компиляторов, причем стабильно с выходом новой версии на случай "а вдруг что то поменяли"

0

Сообщение от sys_beginner Заранее же неизвестно А если приспичит то платить придется дорого

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

Добавлено через 4 минуты

Сообщение от sys_beginner Жесть. Это весь код нужно в АСМ читать, причем для всех компиляторов, причем стабильно с выходом новой версии на случай "а вдруг что то поменяли"

Если вы параноидально занимаетесь оптимизацией на спичках, то да.
Можно ещё и inline-ов с register по всему коду напихать (хотя в этом даже больше смысла будет).
Как бы это не такое узкое место, чтобы настолько его проверять. Если вы не спите по ночам из-за вопроса о производительности в get-методе, ну проверьте вы его один раз в АСМ.

Вообщем, чушь какая-то.

0

Сообщение от MrGluck Найти тонкую грань между паранойей и предусмотрительностью и есть настоящее искусство.

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

В C# это решили немного по другому. Там можно обращаться напрямую к полям но потом их можно переделать под свойства (т.е будет вызвано тело поля - оно уже станет свойством) и там можно реализовать свою логику

Добавлено через 40 секунд

Сообщение от MrGluck Вообщем, чушь какая-то.

Так на С++ и пишут для получения высокой производительности
Почему чушь?

0

> Проблема в том что заранее неизвестно ведь нужно ли будет это или нет

Обычно внешний интерфейс - это отображение некоторых деталей бизнес-области (domain area?). И обычно там многое известно и можно предвидеть.

> Вот вы написали полезную библиотеку и я ею пользуюсь в 1000 местах, вы дали допустим к вашим классам через поля напрямую. Потом вам пришла идея чего-то добавить и прямого обращения недостаточно.

А под это уже можно сделать новый интерфейс. Кто хочет новую фишку, пусть и правит свой код.

0

Сообщение от socslm И обычно там многое известно и можно предвидеть.

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

Сообщение от socslm А под это уже можно сделать новый интерфейс

Ага и заставлять переписывать код пользователей этой самой библиотеки когда можно было просто потянуть с гита актуальную версию библиотеки и скомпилить её

0

Сообщение от sys_beginner Предвидеть можно но нельзя дать гарантии что так будет всегда

Гарантий конечно дать нельзя, но обычно бизнес область менее подвижна, чем обслуживающее её ПО

Сообщение от sys_beginner Ага и заставлять переписывать код пользователей этой самой библиотеки когда можно было просто потянуть с гита актуальную версию библиотеки и скомпилить её

А зачем старый интерфейс убивать? Или убивать не сразу.
Кому новый функционал не нужен, пусть ничего не переписывают и продолжают старый интефейс использовать.

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

0

Сообщение от sys_beginner и заставлять переписывать код пользователей этой самой библиотеки

проблемы индейцев шерифа не...

0

Сообщение от socslm Гарантий конечно дать нельзя

Ну вот об этом и речь Поэтому минусом не считаю если сеттер или геттер ничего не делает кроме установки и возвращения значения. Плюс даже при такой реализации это наличие страховки и стоит очень дешево.

Сообщение от socslm А зачем старый интерфейс убивать? Или убивать не сразу.

Как минимум потому что он больше не актуален

Сообщение от socslm Кому новый функционал не нужен, пусть ничего не переписывают и продолжают старый интефейс использовать.

А кому нужен - пусть мучается Превосходно

Добавлено через 30 секунд

Сообщение от hoggy проблемы индейцев шерифа не...

Только если шериф сам не индеец

0

Сообщение от Someone007 Большинство компиляторов оптимизируют все ваши get/set'ы таким образом как они бы выглядели при прямом доступе к полям.

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

Сообщение от sys_beginner А как проверить была ли оптимизация или нет?

Посмотреть в дизассемблере

Сообщение от sys_beginner Думаю если мы пишем вызов метода нужно быть готовым платить за это

Язык программирования не является вещью в себе. Его проектировали не в вакууме, а под конкретные цели. Устройство inline-методов проектировали в том числе и под то, чтобы можно было писать короткие функции, которые компилятор заменит на встроенный код (по сути дела это есть замена C'шным макросам). Поэтому платить за Set/Get (в их классической реализации) не придётся

Добавлено через 1 минуту

0

Сообщение от MrGluck Если вся реализация класса состоит лишь из скрытых(private/protected) свойств и набора get-set методов для них, при этом нам не нужно (и с высокой вероятностью никогда не будет нужно) дополнительно что-то делать при изменении/обращении к свойству, то смысла в таком классе нет. Гораздо прозрачнее назвать его структурой и обращаться к полям напрямую.

Я бы добавил, что здесь важна не столько неизменяемость класса, сколько его локальность.
Класс, который используется в 5-6 местах и больше нигде, можно вообще писать абы как, с
нарушением всех канонов, поскольку в случае переделок потери на его модернизацию будут
совсем небольшими. А вот если класс используется в 100500 местах, то к его проектированию
нужно подходить очень продуманно, каждая мелочь может сыграть "в минус".

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

1