C++ getters & setters

Ты вот посоветовал голую структуру, а потом сам же повесил конструктор нетривиальный.

по запросу пользователя же :)

>кто Вам сказал что (-1, -1) не валидная точка? :)

Жизнь.

oh shi~

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

это прекрасно, но это всё лирика; с точки зрения же ООП, точка не должна знать о внешнем мире и его ограничениях, не надо натаскивать лишнего

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

а ну покажи

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

то есть 1-е условие для того чтобы стать программистом - изучить С++? не каждется ли Вам что это несколько некорректное требование?

Таким образом нужно завести 2 класса точек: для точек первый квадрат онли и точек с произвольным квадратом.

вот так ложная концепция вызывает костылестроение во все поля

То, что концепций в системе 2, и в каждой из них свои правила игры, это данность, а не «ложность».

>это прекрасно, но это всё лирика; с точки зрения же ООП, точка не должна знать о внешнем мире и его ограничениях, не надо натаскивать лишнего

Точки вообще, вне контекста разработки, внешнего мира и его ограничений, не существует.

> > Поменяется поведение, название метода не будет отражать его суть, присутствующий изначально инвариант setX(1); getX() == 1 - уже не будет выполняться.

Если 1 - валидное значение для X, то инвариант выполняться будет. Если невалидное, то это какой-то вредный инвариант. А в случае структуры - пиши что хочешь, кто хочешь. Теперь в любом месте, куда прилетит такой объект, по-хорошему нужно первым делом контролировать, не случилось ли с ним чего страшного. Или понадеяться, что все будет в порядке.

Точка - это набор чисел для обозначения координат объекта

Координаты объекта существуют только при выбранной системе координат/системе отсчёта

Ограничения на значения координат существуют только в конкретной СК/СО.

Точка о системе отсчёта ничего не должна знать. Сеттеры/геттеры в данном случае только замусоривают код и делают его трудночитаемым. Ни о каких «интерфейсах» здесь речи и быть не может (интерфейс чтения и записи инта в переменную уже и реализован с помошью оператора =, плодить новые сущности ненужно)

то это какой-то вредный инвариант.

Это не вредный инвариант. Почитай вот это: http://en.wikipedia.org/wiki/Liskov_substitution_principle

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

> И тут на определенном наборе данных выясняется, что алгоритм не работает. Какой-то явный бред на выходе. Начинаешь дебажить, видишь, что иногда прилетают точки с отрицательными координатами, которые все портят. Как так? Откуда? Ты же контролируешь входные данные. Приходится отыскивать все места, где идет какая-либо работа с точками и вставлять проверки. В итоге ты конечно баг локализуешь, но бухнешь времени. А простейший сеттер на две строки избавил бы тебя от мучений.

что алгоритм не работает

где идет какая-либо работа с точками и вставлять проверки.

LOL. Значит, заместо того, чтоб исправить неработающий алгоритм/найти косяки в работе с координатами ты предлагаешь замаскировать баг?

Отличное решение!

То, что концепций в системе 2, и в каждой из них свои правила игры, это данность

это не данность - это маразм, так делать

Точки вообще, вне контекста разработки, внешнего мира и его ограничений, не существует.

раз они вне контекста разработки, то нечего и код для них писать

>Ограничения на значения координат существуют только в конкретной СК/СО.

Ты, как и shty, почему-то считаешь, что если в проекте встречается слово «точка», то это просто точка линейного пространства и не надо ее ничем ограничивать. Такая абстрактная точка бесполезна. Если я работаю исключительно с точками в первом квадранте, то точка для меня - это не элемент пространства вообще, а такой элемент пространства, у которого все координаты положительны. И этот факт я отражаю в инварианте класса, выполнение которого контролируется в сеттерах. Далее, это уже задача внешних сущностей - выбрать такую СК, чтобы все рабочие точки были валидны.

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

Прочти внимательней. Там написано, что на вход должны поступать точки из первого квадранта. Это предусловие. Если предусловие не выполнено, то баг не в алгоритме, а непонятно где до него. Сеттер мгновенно и точно укажет место и объект, где кто-то пытается некорректно изменить состояние объекта. А со структурой - ССЗБ.

Для ловли багов есть другие механизмы.

> Такая абстрактная точка бесполезна

Какой бред. Ты, видимо, не понимаешь, что такое ООП. Ты сейчас описываешь систему, основанную на прямом доступе к полям структуры, с использованием «интерфейса» для чтения и записи поля.

Есть интерфейсы, а есть сеттеры и геттеры. Сеттеры и геттеры предоставляют механизм чтения и записи данных в поля класса. Твои попытки оправдать дублирование оператора «=» только вызывают недоумение.

Ну-ну.

http://domaindrivendesign.org/node/91
http://domaindrivendesign.org/node/98


Модульность штука такая - требует усилий для своего достижения.

Ты, как и shty, почему-то считаешь, что если в проекте встречается слово «точка», то это просто точка линейного пространства и не надо ее ничем ограничивать.

не-не-не, кто сказал «не надо ее ничем ограничивать»?

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

а теперь давайте закончим с теорией и перейдём к практике - обоснуйте применение концепций приведённых в Ваших ссылках для описания точки

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

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

Если желаете, вот более абстрактное доказательство:

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

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

Вообще в книжке DDD Эванса целая глава про контексты, не думаю что у меня получится объяснить лучше, чем у него. Так что советую почитать.

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

Скажем, есть такая сущность: ГПСЧ, подробности реализации которого скрыты в классе. Он не знает и знать не желает о контексте, в котором работает, и о том, что клиентскому коду нужны только положительные ПСЧ, или только четные ПСЧ, или только ПСЧ с суммой цифр равной N, или...

Означает ли это, что данный ГПСЧ «деградировал до примитивной структуры без всякой инкапсуляции», или что это «бесполезный, сферический в вакууме» ГПСЧ, или что под каждый частный случай нам нужно написать собственную велосипедную реализацию?

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

4.2

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

в общем случае говорить не готов, но в случае примера с точкой - всё так, и это правильно

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

Есть и более прагматические доводы почему точка должна быть разной в разных контекстах:

простите, но фразу «С точки зрения клиента...» (и далее) я не могу Вам зачесть как довод - это какие-то общие положения, их связь с обсуждаемой проблемой как минимум непрозрачна

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

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

В данном примере ГПСЧ - это, если выражаться терминами самого Еванса, kernel domain.

Случай, что описал я - общий. То, что какая-то сущность может быть полезна любому (или просто нескольким) клиенту - это оптимизация.

в общем случае говорить не готов, но в случае примера с точкой - всё так, и это правильно

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

это называется велосипедостроение,

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

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

Почитайте все же Эванса, он на стратегическом проектировании собаку съел.

так, формулирую простыми словами: оставьте Вы теории, идите от практики, на практике же хватает простой структуры, и используют такие структуры и в кадостроении и в мат. расчётах, а делать «16» сущностей для одной точки в разных «квадрантах» - я бы за такое открутил бы руки

Ещё отдельный класс для точек чётными положительными, нечётными отрицательными координатами и один для точек, у которых координаты делятся на 5.

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

Что касается конкретного примера с точкой: я бы вообще сделал ее immutable, типа такого:

public class Point {
  public final int x;
  public final int y;
  public Point(int x, int y) { this.x = x; this.y = y; }
}

Про тот страх и ужас, порожденный стремлением «упростить», а именно переиспользование всего и вся, что мне довелось увидеть как раз на практике, я уже писал.

не, ну любую, даже самую лучшую, концепцию можно довести до безумия, тут что уж говорить, всё применять надо с умом :)

Что касается конкретного примера с точкой: я бы вообще сделал ее immutable, типа такого:

public class Point {
  public final int x;
  public final int y;
  public Point(int x, int y) { this.x = x; this.y = y; }
}

too javish :)) однако посмотрите, разногласий у нас нет по данному вопросу

>однако посмотрите, разногласий у нас нет по данному вопросу

Я один вижу разногласия между immutable-объектом и структурой?

>Что касается конкретного примера с точкой: я бы вообще сделал ее immutable, типа такого:

А конструктор без параметров как же?

immutable объект - это безпасная такая структура :)

Зачем? Ты про JavaBeans нотацию что ли? :) Если так, то в топку, прямо следом за венгерской нотацией.

>Зачем? Ты про JavaBeans нотацию что ли? :) Если так, то в топку, прямо следом за венгерской нотацией.

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

Смотря какое приложение. Если десктопное - то пофиг, гц не сильно заметен будет. Если сервер под нагрузкой, то уже сложнее :) Жава плохо с таким работает. Но если очень хочется, то можно сделать так: пул мутабельных объектов. Берешь себе сетку с мутабельными точками, заполняешь и работаешь, поработал, вернул в пул. Не супер архитектурно, зато не засирает память мусором.