Нужны ли вообще геттеры сеттеры в классах?

Облегчает рефакторинг и сопровождения, ибо интерфейс не меняется.

Таки да, согласно идеологии скоростного быдлокодинга - ненужно.

Нужны.

Я сейчас из-за отсутствия геттеров/сеттеров имею проблему http://www.linux.org.ru/forum/web-development/4708339 :)

Был бы сеттер - просто переопределил бы его и всё.

А, вообще, за последние пару месяцев было уже два огромных тредосрача на эту тему :)

Хех ну вот я только что накатал класс рыночной свечи, в которой аж 9 изменяемых параметров. И к ним было как-то влом писать 18+ сеттеров/геттеров. Когда я знаю точно как я ее буду использовать.

Впрочем. Если это добро потом наследовать..

Хех не встречал )

К стати, а в какой IDE геттеры сеттеры рефакторингом под С++ делаются? Разве что для жавы такое видел в NetBeans.

Сейчас в QtCreator'e сижу - там такого нема

Облегчает рефакторинг и сопровождения, ибо интерфейс не меняется.

Таки да, согласно идеологии скоростного быдлокодинга - ненужно.

фу, белко, ну что ты как не тролль :)

PS неистово и яростно плюсую

для жавы такое есть везде, и в эклипсе, и в идее, и в нетбинзе.

Если это, скажем, C++ - не обязательно. При необходимости просто переносишь переменную в private, делаешь геттер и сеттер, после чего компилишь и смотришь, где отвалилось. Немного механической работы, но ничего сложного.

Если это, скажем, Python - обязательно. Переложить что-либо на компилятор хрен получится.

man инкапсуляция

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

накатал класс рыночной свечи

Это кто такая? Геморройная свеча - понятно, а что такое рыночная?

Я сейчас из-за отсутствия геттеров/сеттеров имею проблему [django] как лучше ловить изменение значения в модели? :)

Был бы сеттер - просто переопределил бы его и всё.

так в Django же Python, или не?

>Если это, скажем, Python - обязательно. Переложить что-либо на компилятор хрен получится.

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

Кроме того есть property, которые позволяют без особых извращений поменять аттрибут с таким-то названием на геттер/сеттер, не меняя основной код.

http://www.2bull.com/learn/candlestick-anatomy.gif

От такая

К стати, а в какой IDE геттеры сеттеры рефакторингом под С++ делаются? Разве что для жавы такое видел в NetBeans.

Сейчас в QtCreator'e сижу - там такого нема

видел такое в visual studio и codegear rad studio (бывший borland), ни разу не кроссплатформенно

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

>Если это, скажем, C++ - не обязательно.

Я тут смотрю что вроде как тоже не обязательно. Таки у меня класс будет как та же структура - чтобы хранить себе некоторые данные да и все -_-

> Если это, скажем, Python - обязательно. Переложить что-либо на компилятор хрен получится.

Теперь объясни, чем property не выход (для Питона)?

> ты разделяешь интерфейс от реализации и если реализация меняется

Шаманские заклинания.

> Если это, скажем, Python - обязательно. Переложить что-либо на компилятор хрен получится.

Если это Python, то можно не париться. Когда понадобится нетривиальный сеттер, можно на месте параметра сделать property.

Полюсофилы плакали кололись, но продолжали извращать парадигмы проектирования под свой матерный язык программирования.

Не нужны, если хочешь сильнее инкапсулировать данные в объектах. «Наружу» выставляются только самые необходимые рычаги управления.

Делать поля публичными заместо геттеров/сеттеров тоже лучше избегать всеми фибрами, так как это ещё больше открывает доступ к неспецифицированному управлению объектом и, как следствие, — невообразимые глюки.

>> Если это, скажем, Python - обязательно. Переложить что-либо на компилятор хрен получится.

Теперь объясни, чем property не выход (для Питона)?

Однако синхронизация у нас с точностью до секунды =)

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

Классический пример - объект Event и у него final поле source, стоит ли его закрывать геттером?

Шел бы ты в лес, упоротый скунс.

> ты разделяешь интерфейс от реализации и если реализация меняется

Шаманские заклинания.

с чем то не согласен?

Теперь объясни, чем property не выход (для Питона)?

Согласен, забыл про проперти.

>>> ты разделяешь интерфейс от реализации и если реализация меняется

Шаманские заклинания.

с чем то не согласен?

С тем, что расходы на «отделение интерфейса от реализации» никак вообще не учитываются.

Можно увидеть ваше портфолио очищенных мышек?

У Вас заболевание психики в виде избыточной оптимизации кода, Вам бы на ассемблере мышки чистить.

> Можно увидеть ваше портфолио очищенных мышек?

Ты меня нанять хочешь или от природы любопытен?

С тем, что расходы на «отделение интерфейса от реализации» никак вообще не учитываются.

простите, но это туфта, используйте inline и никаких накладных расходов не будет

или Вы про что?

>> С тем, что расходы на «отделение интерфейса от реализации» никак вообще не учитываются.

простите, но это туфта, используйте inline и никаких накладных расходов не будет

Самое веское оправдание [сг]еттеров - это сохранение ABI при переходе от поля к чему-то более сложному. А тут inline %)

или Вы про что?

Я про ненужное загромождение кода.

А ПВОВНВ?

Я про ненужное загромождение кода.

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

Я про ненужное загромождение кода.

простите, но может тогда всё писать вообще в main()?

конечно нужны, это же основы ООП. читай классику, там все написано.

> простите, но может тогда всё писать вообще в main()?

Иногда - именно так.

> простите, но может тогда всё писать вообще в main()?

Иногда - именно так.

ха-ха-ха :) ну разве что для «hello, world»

> А ПВОВНВ?

Я изучаю реакцию говорящих скунсов на внешние раздражители.

Вы из того народца

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

> 9 изменяемых параметров. И к ним было как-то влом писать 18+ сеттеров/геттеров

а зачем на каждую переменную писать? можно их кучками же юзать. setDimensions(height,width,depth,weight); например.

>>> простите, но может тогда всё писать вообще в main()?

Иногда - именно так.

ха-ха-ха :) ну разве что для «hello, world»

Да, именно так. А если ты делаешь сложный объект, но при этом у его полей есть геттеры и сеттеры - подумай, правильно ли ты его спроектировал.

P.S. блин, ну даже в Яве давно стало общим местом то, что массовое использование геттеров и сеттеров - это нарушение инкапсуляции и признак плохого проектирования (люди не могут спроектировать нормальный интерфейс для класса и лепят [сг]еттер - типа «ну если реализация изменится, это нас спасет').

>а зачем на каждую переменную писать? можно их кучками же юзать. setDimensions(height,width,depth,weight); например.

Можно и так, но так слишком длинные да неповоротливые строки выходят.

Да и к тому же у меня парсится csv с этими данными, где они содержатся в строках. и чтобы не плодить еще кучу переменных, сразу при распарсевании заношу в setHeight(), setWith и т.д.

> Да и к тому же у меня парсится csv с этими данными

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

Я изучаю реакцию говорящих скунсов на внешние раздражители.

Перевод: я играю в доктора, но в роли поциента.

нужных для этого органов.

Вы думаете сиськаме, убогие.

> P.S. блин, ну даже в Яве давно стало общим местом то, что массовое использование геттеров и сеттеров - это нарушение инкапсуляции и признак плохого проектирования (люди не могут спроектировать нормальный интерфейс для класса и лепят [сг]еттер - типа «ну если реализация изменится, это нас спасет').

массово, т.е. на каждое свойство объекта, оно и не нужно. но оно часто незаменимо.

Вы уже почистили мышку, а под ней? А то вижу Вы склонны всем советовать как надо с точки зрения быдлокодера.

даже в Яве давно стало общим местом то, что массовое использование геттеров и сеттеров - это нарушение инкапсуляции и признак плохого проектирования

а таки Вы в этом смысле :) ну да, нефиг ко всем подряд данным класса лазать

массово, т.е. на каждое свойство объекта, оно и не нужно

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

но оно часто незаменимо.

Ну объясни мне, что незаменимого в методах вроде:

int getField() { return _field; }

void setField(int v) { _field = v; }

>> даже в Яве давно стало общим местом то, что массовое использование геттеров и сеттеров - это нарушение инкапсуляции и признак плохого проектирования

а таки Вы в этом смысле :)

Нет, я еще и в смысле «Hello, world!\n» - нефиг каждой структуре лепить [сг]еттеры.