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

>> если ты и правда:

начинал кодить на Си++ еще в Turbo C++

Правда

то должен бы и сам знать ответ на вопрос :)

Я его знаю. Просто это не тот ответ, который знаешь ты.

> теперь если мы поменяем _field у foo то в скольких местах нам придётся менять код?

А если я захожу поменять _field на _shmield и соответственно *et_field() на *et_shmield()? То в скольких местах нам придётся менять код?

В яве, так одни чрезжопности и подпорки.

> А если я захожу поменять _field на _shmield и соответственно *et_field() на *et_shmield()?

Ты не должен хотеть менять get_field :)

если я захожу поменять [..] *et_field() на *et_shmield()

чувствуете разницу в изменении реализации и изменении API или не очень?

> чувствуете разницу в изменении реализации и изменении API или не очень?

Чувствуете разницу в изменении опубликованного API библиотеки и внутренних API?

Вы не должны хотеть советовать того в чем нихрена не смыслите.

В вашем примере? Нет.

В вашем примере? Нет.

я Вам какой то пример приводил на эту тему?

> И тут вдруг задумался... А зачем, если можно проще?

Тривиальные реализации сеттер/геттер идут вразрез с OO-дизайном (лучшее - враг хорошего). С тем же успехом можно просто выставить нужное поле в public, после чего выкинуть ваш класс на помойку и заняться какой-нибудь менее интеллектуальной работой, например, доставкой пива. Об этом еще МакКоннелл писал в книге «Совершенный код», ЕМНИП.

> чувствуете разницу в изменении реализации и изменении API или не очень?

Чувствуете разницу в изменении опубликованного API библиотеки и внутренних API?

да, и разница в масштабе бедствия, а Вы чувствуете?

>> Чувствуете разницу в изменении опубликованного API библиотеки и внутренних API?

да, и разница в масштабе бедствия, а Вы чувствуете?

Изменение внутренних API - это не бедствие, а нормальная работа. Тем более, такое тривиальное изменение, как переименование поля/*еттера.

Изменение внутренних API - это не бедствие, а нормальная работа.

такой наивный малтшик :) и как часто, в среднем ты меняешь API? я вот, например, сначала рисую UML диаграммы и мне менять практически ничего не надо потому что API спроектировано :)

> такой наивный малтшик :)

А правда, что называть оппонента «школием» и «мальчегом» любят именно школьники?

и как часто, в среднем ты меняешь API?

Не часто, но бедствий не замечал.

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

То есть поля ты не переименовываешь? -1 usecase для *еттеров.

потому что API спроектировано :)

Если ты настолько крут, что с всё первого раза получается правильно, тогда я прекращаю спорить - ты из другой весовой категории %)

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

http://martinfowler.com/bliki/GetterEradicator.html

I'm loving all the butthurt comments from developers who've just realised their code sucks. Throwing around hyperbole, without any examples/arguments to refute...

точно знаю, что процесс размышления некоторые заменяют процессом запоминания.

чуть более чем некоторые. увы

расскажи пожалуйста - а как тебя защитят геттеры/сеттеры от случая, когда поле в реализации не поменяет название, а пропадёт?

у нас же инкапсуляция, ну. независимость интерфейса и реализации

расскажи пожалуйста - а как тебя защитят геттеры/сеттеры от случая, когда поле в реализации не поменяет название, а пропадёт?

struct Point
{
    int x;
    int y;
};
...
Point p1 = { 1, 1 };
Point p2 = { 2, 2 };
...
DrawLine( p1, p2 );

показывай, как умные джависты защитятся тут от пропадания поля

а зачем менять имена полей?

в DrawLine ес-но идет обращение к x и y

А про инкапсуляцию вам не рассказывали, да?

показывай, как умные джависты защитятся тут от пропадания поля

ты упоролся? или в состоянни священного аффекта у тебя пропадает способность читать?

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

> ты упоролся? или в состоянни священного аффекта у тебя пропадает способность читать?

сам дурак

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

здорово, а теперь вытри слюни и покажи как этот пример напишешь ты

покажи как этот пример напишешь ты

твой пример, увы, нерепрезентативен - у желаемого тобой простого типа Point интерфейс состоит из полей x и y; случай исходного поста (9 изменяемых параметров) такая ситуация вряд ли имеет место быть

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

http://www.codenet.ru/progr/cpp/cpp-properties.php

> твой пример, увы, нерепрезентативен - у желаемого тобой простого типа Point интерфейс состоит из полей x и y; случай исходного поста (9 изменяемых параметров) такая ситуация вряд ли имеет место быть

кол-во полей влияет на то как с ними надо работать? интересно... ;)

по существу о направлениях проектировании есть возражения?

а разве нельзя спроектировать класс с полями и геттерами? в чем их зло? то что ты написал про удаление поля - ну не серьезно, большинство полезных библиотек написано на С, и ничего - живут люди( потому-что как раз думают очень хорошо перед тем как писать )

Маниакально засовывать все поля в private и делать сразу же для каждого геттер и сеттер точно не нужно. Например, у std::vector есть геттер для data, но нет сеттера. Вообще, интерфейс объекта должен отражать не его внутреннюю структуру, а его назначение. Если язык позволяет сделать property с запрятанными геттером и сеттером внутри, то лучше так и сделать, потому что удобнее.

> http://www.codenet.ru/progr/cpp/cpp-properties.php

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

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

А кто сказал, что такой дизайн класса Event хороший?
При таком дизайне, даже если поле source будет final, во время работы приложения будет возникать лавина объектов Event с последующей утилизацией GC. Такое приемлемо для переменных, время жизни которых ограниченно (на стеке вызовов). Зачем это нужно для объектов — большой вопрос.

Если бы поле source было изменяемым и закрыто сеттером/геттером, то объекту Event можно было бы легко продлить время жизни вплоть до времени жизни самого приложения без растраты вычислительных ресурсов — пул из:
1) порождённых;
2) ожидающих обработки в очереди;
3) обработанных;
4) очищенных event'ов.
— последние готовы для выполнения новых миссий по передаче информации от источника (изменяемое поле source) к приёмнику сообщений без необходимости работы GC и инстанцирования новых объектов.

> Если язык позволяет сделать property с запрятанными геттером и сеттером внутри, то лучше так и сделать, потому что удобнее.

C++ позволяет - но скорость работы при этом упадет раз в 10

кол-во полей влияет на то как с ними надо работать?

не должно; однако как только мы вынесли для этих полей сеттеры/геттеры - влияет, т.к. мы завязали на них интерфейс

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

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

то что ты написал про удаление поля - ну не серьезно

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

большинство полезных библиотек написано на С, и ничего - живут люди

именно потому, что private сам по себе никакой инкапсуляции не обеспечивает; обеспечивает её грамотно спроектированный интерфейс, с минимальной зависимостью между уровнями абстракции - независимо от того, объектный этот интерфейс, процедурный или функциональный

> не должно; однако как только мы вынесли для этих полей сеттеры/геттеры - влияет, т.к. мы завязали на них интерфейс

т.е. ты за прямое обращение к полям в данном случае?

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

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

не имея в интерфейсе привязки к конкретным полям реализации мы имеем возможность менять эти поля произвольным образом

вот из-за этой твоей позиции я и привел пример с Point - нельзя подгонять все под одну гребенку

Аа. Надо меньше читать треды по диагонали :)

Добавить в шаблон метод T& ref() :)

т.е. ты за прямое обращение к полям в данном случае?

зависит от проекта, скорее всего - да; это несомненно ухудшит инкапсуляцию, но в силу принципа kiss для 90% проектов абстракия точки работает именно так

для сколько-нибудь сложных типов открытых полей я делать не буду (равно как и всячески буду избегать наличия сеттеров/геттеров)

нельзя подгонять все под одну гребенку

почему же? инкапсуляция в случае Point будет слабенькая, просто именно такой уровень инкапсуляции хорошо укладывается в общую архитектуру

> для сколько-нибудь сложных типов открытых полей я делать не буду (равно как и всячески буду избегать наличия сеттеров/геттеров)

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

инкапсуляция в случае Point будет слабенькая

в чем именно она будет проявляться, если она будет?

в чем именно она будет проявляться, если она будет?

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

авторов ее не так часто былокодерами называют

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

>инкапсуляция в случае Point будет слабенькая, просто именно такой уровень инкапсуляции хорошо укладывается в общую архитектуру

Да никуда она не укладывается. Это пример того, как НЕ НАДО проектировать класс Point (и Dimension в Java).

Джошуа Блох советует ограничивать область видимости этих, с позволения сказать, классов областью видимости пакета, чтобы они не были видны за пределами пакета ВООБЩЕ.

Теперь Dimension — вечная головная боль.

Да никуда она не укладывается

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

> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

http://martinfowler.com/bliki/GetterEradicator.html

Спасибо. Хорошие ссылки.

> Теперь Dimension — вечная головная боль.

И в чем же его головная боль? Я давно не пишу на Яве, но никакой головной боли от Dimension не припомню.

> следовало бы, на самом деле

спердобейся :) шучу, на самом деле С++ терпят и пишут на нем потому-что он «быстрый», а концепция заинлайненых геттеров/сеттеров практически ничем не отличается от прямого доступа к полю ( за исключением того факта, что их потом можно будет изменить в случае надобности - добавить проверки, сменить поле на вычисляемое выражение и т.д., что есть плюс ), итого странно предъявлять претензии к языку, библиотекам и программистам в отрыве от этого факта, те кому не важна скорость, а важна «чистота» языка и решений - должны подумать, а зачем они выбрали С++, и почему они учат плюсовиков как писать, если у тех другие задачи

Спасибо. Хорошие ссылки.

пожалуйста, рад что пригодились

но опять же - это просто предпочтение, взять библиотеку вроде Qt( если говорить про С++ ) - то тут сплошь и рядом сеттеры/геттеры,

Тащемта там есть пара классов с прямым доступом к свойствам

> такой наивный малтшик :)

А правда, что называть оппонента «школием» и «мальчегом» любят именно школьники?

не знаю, возможно, но я Вас ни «школием» ни «мальчегом» не называл :)

это была реакция удивления на фразу

Изменение внутренних API - это не бедствие, а нормальная работа.

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

мне приходилось перекраивать API некоторых модулей на толстом проекте, радость та ещё

> и как часто, в среднем ты меняешь API?

Не часто, но бедствий не замечал.

вот именно что не часто :) в том смысле что это редко требуется при правильно подходе к разработке

а бедствия они начинаются когда меняется API модуля прокинутого через кучу других, как, например, в парадигме MVC модуль с данными, тогда приходится перековыривать половину проекта и исправлять

> потому что API спроектировано :)

Если ты настолько крут, что с всё первого раза получается правильно, тогда я прекращаю спорить - ты из другой весовой категории %)

нет, но удаётся снизить количество модификаций внутренних API

расскажи пожалуйста - а как тебя защитят геттеры/сеттеры от случая, когда поле в реализации не поменяет название, а пропадёт?

у нас же инкапсуляция, ну. независимость интерфейса и реализации

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

а зачем менять имена полей?

ну емае, это пример :) шо Вы передёргиваете

может поменяться вообще вся начинка класса, внутри может быть не 1 поле, а 5 из которых считается искомое значение, включаем воображение, вспоминаем что такое рефакторинг

> мы здесь что-то помимо нормальной работы обсуждаем?

Мы? Нет. Ты почему-то говорил о каком-то «бедствии».

а бедствия они начинаются когда меняется API модуля прокинутого через кучу других

Ты хочешь сказать, что серьезные переделки API тродоемки? Да ты просто Капитан Очевидность. Вопрос в том, насколько тебе помогут *еттеры, особенно - тривиальные *еттеры.

Если ты настолько крут, что с всё первого раза получается правильно, тогда я прекращаю спорить - ты из другой весовой категории %)

нет, но удаётся снизить количество модификаций внутренних API

То есть тщательное проектирование - это хорошо? Спасибо, Капитан. Только непонятно, причем тут *еттеры.

в оставшемся методе *еттера пишем заглушку

прекрасная, прекрасная техника. работники костыльной фабрики апплодируют стоя

в оставшемся методе *еттера пишем заглушку

прекрасная, прекрасная техника. работники костыльной фабрики апплодируют стоя

это Вы со своими коллегами щитоле?

Вопрос в том, насколько тебе помогут *еттеры, особенно - тривиальные *еттеры.

перечитай тред, там всё есть, а про тривиальные *еттеры - это ты говорил

Только непонятно, причем тут *еттеры.

перечитай тред +1