C++ getters & setters

>А это самый распространненый объектный язык в мире

Говорят, что объектный язык - это тот, в котором нету наследования

if( VALID_PTR( obj ) )

Мне кажется такие вещи лучше делать как-то так:

ASSERT( obj );

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

Я бы сказал иначе - наследование, оно как бы ортогонально объектам. Вообще системы классов ортогонально объектности. Это глобальное запудривание мозга объектная _ориентированность_ заключается в системе классов, которая отрогональна и вообще отчуждаема относительно объектов. Как в том же хаскеле: объектов нет, классы есть.

И таки да, когда я пишу на жаве стараюсь как можно меньше наследовать. Больше агрегировать.

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

Видимо, имелось в виду «ушли из релиза»? Не стоит. Ассерт в общем случае означает «здесь может быть вот такая фигня, с которой я не знаю, что делать дальше». Это приемлемо для рабочей версии, когда обкатывается/тестируется чужой код/библиотека, но не приемлемо для продакш кода. «Неизвестной фигни» там быть не должно.

Если ассерт дожил до релиза - это косяк.

По-моему, ты не понял содержание моего поста. Перечитай его еще раз. Вдумчиво.

>Просто ты знаешь, что все манипуляции с Point нужно проводить через PointService.

Это тот же if, если я правильно понимаю о чем речь. Есть объект с набором полей. Есть множество его состояний. Часть состояний валидные, часть - нет. Если любым способом отделить проверку валидности от изменения состояния объекта, то мы уже не можем гарантировать, что состояние объекта всегда валидно и перед каждым использованием вынуждены будем вызывать какую-то проверку. Это и есть размазывание кода в моем понимании.

> Мне кажется такие вещи лучше делать как-то так:

для выражений, вроде index < count так и делается

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

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

А то как-то топорненька, по-ламерски.

я на роль профи и не претендовал - работает, не падает, уже хорошо

> неужели правда все вокруг доказывают?

Кто говорил про «всех вокруг»? Речь шла о «всех приличных людях». Про чукчей, которые что в голову взбредут, то и пишут, речь не шла.

А какая разника как ты изменяешь состояние объекта: point.setX(...) или pointService.setX(point, ...)? Никакого отделения валидности от изменения состояния нету. И никакого размазывания логики нету.

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

> выпиливается же

выпиливаться должно автоматом по ключу при компиляции, ваш иф можно выпилить только ручками, насколько я знаю.

А вот объясните мне пожалуйста, как Вы будете через сеттеры с проверкой изменять координаты той же точки на плоскости, если условие валидности x*y>0, и Вам из первого квадранта надо перескочить в третий?

>Кто говорил про «всех вокруг»? Речь шла о «всех приличных людях». Про чукчей, которые что в голову взбредут, то и пишут, речь не шла.

Тогда так поставлю вопрос. Кто еще в треде использует математическое доказательство корректности своего кода? Чтобы спросили - «а что это у тебя тут проверок никаких нет?» А ты им - раз и стопку теорем.

> выпиливаться должно автоматом по ключу при компиляции, ваш иф можно выпилить только ручками, насколько я знаю.

плохо знаете, VALID_PTR - это макрос( что видно из регистра символов ), который как раз и меняется в зависимости от «ключей компиляции»

Есть такое понятие в проектировании, называется контекст сущности. Так вот в каждом контексте должна быть своя сущность. Таким образом нужно завести 2 класса точек: для точек первый квадрат онли и точек с произвольным квадратом. Между контекстами сделать конвертер и вооще контексты разделить фассадами а еще лучше http. Где делать валидацию: в сетере или сервисе - пофиг, главное не смешивать разные понятия, иначе в переделе сущность удовлетворяющяя всем контекстам превращяется в набор публик полей.

> плохо знаете, VALID_PTR - это макрос( что видно из регистра символов ), который как раз и меняется в зависимости от «ключей компиляции»

А не нужно чтобы он менялся, нужно чтобы ифа в релизе там вообще не было никакого.

Кстати вариант с паблик полями тоже не плох. По сути это пудет kernel сущностью. А вот логика валидации будет разная в разных сервисах.

>А какая разника как ты изменяешь состояние объекта: point.setX(...) или pointService.setX(point, ...)? Никакого отделения валидности от изменения состояния нету. И никакого размазывания логики нету.

Если бы poinService был единственный, кто может изменить состояние point, то разницы бы не было. А так это эскалирование проверок с технологического уровня на организационный («а давайте договоримся, что будем писать правильно и не будем неправильно»). Это менее надежно, мне кажется, хотя в ряде случаев (например, если пишет один человек, или невалидных состояний у объекта особо и нет), никакой разницы.

А так это эскалирование проверок с технологического уровня на организационный

Ой да это мелочь такая, как будто других проблем нету в проекте :) Если бы все было идеально, можно было бы посидеть и порефакторить.

Но есть один сомнительный правда, но плюс в использовании сервисов, который я описал выше: имея несколько сервисов можно юзать один и тот же Point в разных контекстах со своей логикой валидации и прочего. Впринципе прагматичный такой подход.

А не нужно чтобы он менялся, нужно чтобы ифа в релизе там вообще не было никакого.

Если VALID_PTR раскрывается в false и сборка с оптимизацией, то его там и не будет скорее всего.

>А вот объясните мне пожалуйста, как Вы будете через сеттеры с проверкой изменять координаты той же точки на плоскости, если условие валидности x*y>0, и Вам из первого квадранта надо перескочить в третий?

Я там не за сеттеры агитировал, а за валидацию параметров перед изменением состояния объекта. За сеттеры я агитировал перед голой структурой.

> А не нужно чтобы он менялся, нужно чтобы ифа в релизе там вообще не было никакого.

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

>Но есть один сомнительный правда, но плюс в использовании сервисов, который я описал выше: имея несколько сервисов можно юзать один и тот же Point в разных контекстах со своей логикой валидации и прочего. Впринципе прагматичный такой подход.

Я за привязку валидации состояния к типу объекта: [code=cpp] template< typename VALIDATION_POLICY = DEFAULT_VALIDATION > struct Point; [/code]

Но тут уже бессмысленно спорить, конечно. Как кому опыт подсказывает.

> http://www.linux.org.ru/forum/development/6013294/page2#comment-6015623

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

Кнут с TeX'ом.

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

> почему? в любом случае лучше явно обработать ошибку, пусть это будет бросок исключения, вывод сообщения, завершение работы или т.п., чем допустить выполнение кода с некорректными данными

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

http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf

Вот там вроде написано про то, как формальные методы в наса применяют.

>Кнут с TeX'ом.

Ты имеешь в виду отдельные алгоритмы, типа поиска подстроки, или весь TeX?

Вот тоже про НАСА, но это уже чисто «на поржать»

http://kholeg.wordpress.com/2006/11/20/они-пишут-правильную-вещь/

O_O ...

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

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

Я это слышал от кого-то и у меня даже пруфов нет.

>Я это слышал от кого-то и у меня даже пруфов нет.

От Кнута всего можно ждать - он reusable code не признает.

> А ты им - раз и стопку теорем.

Тебе в школе значение терминов «предусловие» и «постусловие» не объясняли?

Доказать можно (и нужно) только что-то конептуально целостное и имеющее формальную постановку. Если у вас такого много, я вас поздравляю.

Т.е. все твои программы написаны не формально?

Э, слышь, комп, сгоняй, принеси чё-нить..

?

>Тебе в школе значение терминов «предусловие» и «постусловие» не объясняли?

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

что-то конептуально целостное и имеющее формальную _постановку_.

Написаны-то они максимально формально. Часто вам ТЗ приходит в виде формально доказанных спецификаций? Если у вас что-то с математикой связаное, то так оно и должно быть. А так обычно треш из хотелок пользователей.

Контракты хорошо работают только для элементарщины вроде стека. Или чего-то очень формального.

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

> Часто вам ТЗ приходит в виде формально доказанных спецификаций? ...
А так обычно треш из хотелок пользователей.

Ну, если ты берешься реализовать треш, не разрулив все неоднозначности, - ССЗБ.

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

>Контракты хорошо работают только для элементарщины вроде стека.

У меня редкий метод обходится без предусловия. Часто в сеттерах как раз) Это помогает при прогонах тестов. Только к доказательству корректности это очень отдаленное отношение имеет.

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

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

Только вот проблемы обычно реально лежат не на уровне «кода», а на органищационном уровне: кто-то хочет странного, кто-то не понял что от него хотят, кто-то реализует не так из религиозных соображений и так далее. А всякте мелочи вроде пред и пост условий и прочего при отладке выявляются запросто. Не разу не видел, что бы проект так и кишил null pointer exception-ами или чем-то похожим.

>Норкаман? Может ты еще спросишь, является ли наличие доказательства правильности гарантией от ошибок?

Пре/постусловие - это у тебя доказательство правильности? У тебя наверное, весь код так «доказан»:

[code=cpp] bool not( bool arg ) { assert( arg == false || arg == true ); if( clock() % 17 == 0 ) { puts( «narkoLamer attacks» ); exit( 100500 ); }

bool result = ! arg; assert( result == ! arg ); } [/code]

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

Пре/постусловие - это у тебя доказательство правильности? У тебя наверное, весь код так «доказан»:

bool not( bool arg )
{
  assert( arg == false || arg == true );
  if( clock() % 17 == 0 )
  {
    puts( "narkoLamer attacks" );
    exit( 100500 );
  }

  bool result = ! arg;
  assert( result == ! arg );
}

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

Понимаешь разницу между формальным доказательством корректности и повышением уверенности?

> Пре/постусловие - это у тебя доказательство правильности?

Скажи просто, «Да, норкаман». Я всё пойму.

>Только вот проблемы обычно реально лежат не на уровне «кода», а на органищационном уровне: кто-то хочет странного, кто-то не понял что от него хотят, кто-то реализует не так из религиозных соображений и так далее. А всякте мелочи вроде пред и пост условий и прочего при отладке выявляются запросто. Не разу не видел, что бы проект так и кишил null pointer exception-ами или чем-то похожим.

В джаве непросто добиться null pointer exception-а, да. Пре/постусловия, как раз упрощают отладку. Косяк виден еще до того, тест зафейлился. Можно и так, но лучше ускориться.