C++ getters & setters

что за либа, если не скерет?

http://www.nuance.com/

> кому-то же надо и сложными задачами заниматься.

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

> Для вас программист гений, который помнит всегда и все?

причем тут это? но да, программист должен помнить хотя бы один принцип - KISS

> причем тут это? но да, программист должен помнить хотя бы один принцип - KISS

При том, что если библиотека не валидирует данные, то это задача программиста

> При том, что если библиотека не валидирует данные, то это задача программиста

для вас любой осиливший STL - гений что-ли?

IMHO, самый разумный подход описан вот здесь. И вообще там много чего хорошего написано.

>обрати внимание - я не возражаю против их использования: я возражаю против проектирования от реализации, а в данном случае интерфейс вполне себе предполагает у точки наличия проекций на x и y

Автор статьи нагнетает намного сильнее, говоря, что наличие аксессоров - это и есть признак проектирования от реализации или от безысходности, приводя пример JDBC.

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

спасибо - поднял настроение

не за что. тебе полезно

сложные задачи в твоем понимании это что?

эмуляция проекта на >>1MLoC под кастомное железо на x86, включая OpenKODE с проприетарными расширениями от nVidia. проектирование архитектуры аналогичного проекта под новое железо. RT видео-подсистема, гарантированно запускающаяся менее чем за секунду после холодного старта. драйвера контроля прошивки и диагностики системы. чем-то вот таким я занимался последние три с половиной года

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

…самый разумный подход описан вот здесь.

Точнее, раздел 4.10.2.

эт, ссылку растаращило. ну да я думаю, и так понятно

полностью абстрагироваться от реализации - это утопия.

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

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

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

Судя по тому, что ты сам отвечаешь, то ты себе эти вопросы и задаешь

вопрос я, вообще-то, тебе задал

> эт, ссылку растаращило. ну да я думаю, и так понятно

мне бы больше подошла ссылка на changelog,рассылку,багтрекер etc., может ты там кофе разносил ;) хотя конечно - ты никому ничего не должен доказывать

как работется с немцами?

мне бы больше подошла ссылка на changelog,рассылку,багтрекер etc., может ты там кофе разносил ;)

а вот тут, извини, ничем помочь не могу. на вопрос я тебе ответил

как работется с немцами?

нормально. они педантичные, безэмоциональные, но весьма хороши в профессиональном плане (и гордятся этим)

хотя как по мне, так те же голландцы намного лучше :)

>А часто нельзя.

В тупом примере с точкой - даже нужно.

>вопрос я, вообще-то, тебе задал

Тогда «нет» на все вопросы. Но логической связи с первоначальным вопросом - не вижу. Аксессоры нужны, у тебя не получится спроектировать мало-мальски сложную систему, не используя аксессоров. Вот shty привел код, который, по его мысли, должен был показать, что аксессоры не нужны при правильном проектировании. И вляпал туда аксессор. Yareg говорил, что изменяемые объекты не нужны, надо все в конструкторах контролировать, но не рассказал, как достучаться до свойств иммутабельных объектов без геттеров. А автор разоблачительной статьи про аксессоры написал To-Do List на GWT и теперь смотрит на всех усталыми мудрыми глазами.

>В тупом примере с точкой - даже нужно.

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

Дальше уже сказали, что точка должна быть не просто точкой, а ещё и верифицировать себя. И почему это нельзя?

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

> для вас любой осиливший STL - гений что-ли?

Не осиливший STL вообще не может считаться программистом

> Не осиливший STL вообще не может считаться программистом

amen

>И почему это нельзя?

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

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

В моем понимании геттер - это свойство на чтение. Мне непонятно противопоставление «не геттер, а часть интерфейса». Геттер и формирует интерфейс класса, наряду с другими свойствами и методами. Этот интерфес может быть хорошим, удобным, а может быть - нет.

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

>ты потеряешь возможность хранить её в стандартных коллекциях

ШИТО? Тот же int по своей сути является иммутабельным. Именно в таком же смысле как та точка. a+=2 - это не изменение инта, а создание нового.

Если класс удовлетворяет условию POD, то он POD и есть. Это не значит, что там 2 разные сущности есть где-то.

>ШИТО? Тот же int по своей сути является иммутабельным. Именно в таком же смысле как та точка. a+=2 - это не изменение инта, а создание нового.

Я не знаю, что ты вкладываешь в слово «по сути», но на практике, если ты напишешь класс с конструктором( x, y ) и двумя константными методами, тебе будет очень сложно жить дальше.

> Что такое класс?

Реализация публичных интерфейсов.

К.О.

> Для отслеживания внутренних ошибок нормальные люди используют ассерты ... , а не if'ы лепят.

Это только малограмотная школота, которая не знает, что ассерты выпиливаются из релизной сборки с чистой совестью.

> Ты что, математически доказываешь корректность всех своих вычислений

Ну, вообще-то все приличные люди так и делают.

> Для проверки валидности тупо заводится метод bool check()


Какой же ты тупой...

Какая разница в использованием класса с конструктором и двумя методами и с двумя геттерами/сеттерами, кроме той, что во втором случае проще написать говнокод, который поломает программу? К тому же тебе всё равно нужен конструктор, который будет дублировать функционал сеттеров. Да и вообще пример с точкой очень тупой. Нужно смотреть на гораздо больший кусок кода и смотреть, действительно ли там нужны аксессоры или архитектура - говно.

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

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

Ага, а вот налепить if'ов, а потом выискивать место, из которого ошибка вернулась — это true way. Пиши ещё.

> Ага, а вот налепить if'ов, а потом выискивать место, из которого ошибка вернулась — это true way. Пиши ещё.

ассерты прекрасно «уживаются» с if'ми, у меня например вообще это может выглядеть так:

if( VALID_PTR( obj ) )

в данном случае проверится, что obj - не NULL и не мусор, если не так - в дебаге вываливаемся в дебаггер на данную строку, в релизе - заносим стек + не сработавшее условие в логи

Бля. Не х себе if

Бля. Не х себе if

ага, зато если ты напишешь

delete obj;
if( VALID_PTR( obj ) )
    obj->foo();

или

obj = reinterpret_cast<Obj*>( 123123 );
if( VALID_PTR( obj ) )
    obj->foo();

ничего не упадет, и да - для performace release это развернется в простой if( obj ), но это уже для обкатанной стабильной версии с минорными изменениями

Блин. У меня вообще в коде не бывает ситуаций, когда может появится невалидный объект

> Блин. У меня вообще в коде не бывает ситуаций, когда может появится невалидный объект

у меня библиотека - ей пользуются разные люди, и очень по-разному :)

А геттеры должны быть не геттерами, а частью интерфейса

exactly my point

Гы, забавно. Нужны геттеры или сеттеры сильно зависит о том, что концептуально представляет собой класс. Если класс описывает просто некие холдеры данных - в жопу гет/сет мусор чисто из соображений KISS. Что касается размазывания логики - не придуривайтесь, будто у вас амнезия и вы забыли что такое процедурное программирование и как там решаются проблемы с дублированием логики.

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

Пример с точкой вообще дурацкий, я с большой вероятностью сделал бы ее либо immutable либо persistent.

>Какая разница в использованием класса с конструктором и двумя методами и с двумя геттерами/сеттерами, кроме той, что во втором случае проще написать говнокод, который поломает программу?

В случае константного объекта пользователь в принципе не может изменить состояние после создания и нам ничего не грозит, правда и класс такой бесполезен. Но ты можешь решиться всех обхитрить, определить еще и тривиальный конструктор, а оператор присваивания компилятор услужливо доопределит сам. Такой объект можно уже нормально хранить, вот только от его константности ничего не остается. Между «не можем изменить состояние» и «можем изменить состояние целиком» - большая разница. Фактически ты метод move(x,y) определил. Тебе же не придет в голову класс с таким методом называть иммутабельным и особой разницы с сеттерами тут нет.

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

Согласен, надо каждый раз смотреть и разбираться. Я с этого и начал.

>Ну, вообще-то все приличные люди так и делают.

За всю жизнь слышал только про титанический труд создателей системы управления парижским метро, которые доказали 100500 лемм и про писателей книг, которые доказывали корректность алгоритма Евклида для нахождения НОД, «а дальше вы уж как-нибудь сами». В реальности нигде не наблюдал, неужели правда все вокруг доказывают?

> у меня библиотека - ей пользуются разные люди, и очень по-разному :)

Вот вот. Проблема проектирования. В си нельзя сделать проверки. а вот в С++ можно

А как же асбтрагировать всё и вся?

Статейку почитаю…

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

Как решаются?

Вот вот. Проблема проектирования. В си нельзя сделать проверки. а вот в С++ можно

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

> там голые указатели во все поля

и геттеры/сеттеры, да :)

Очень просто - набор процедур для работы с объектом + модульность. Кто пишет на java, знает про такую штуку, как сервис. В любом жавном проекте тысячи их! Просто ты знаешь, что все манипуляции с Point нужно проводить через PointService. Вообще если посмотреть на подходы, пропагандируемые EJB и Spring, то видно, что никакой инкапсуляции на уровне сущностей нету. Тупые объекты, обвешаные гетерами и сетерами, причем без всякой логики валидации. Можно заменять на public поля спокойно. А это самый распространненый объектный язык в мире. Делайте выводы о том на сколько книжные теории востребованы на практике.

ЗЫ. Я нисколько не поддерживаю подход по типа Anemic Domain Model (http://martinfowler.com/bliki/AnemicDomainModel.html) для всех сущностей, принятый в жава-мире. Просто хочу сказать, что можно преспокойно жить перенеся обязаности по инкапсуляции с сущностей на сервисы.